[Python-3000] Generic functions

[Paul Moore]

On 4/4/06, Ian Bicking <ianb at colorstudy.com> wrote:
> > Perhaps. The import-for-side-effect requirement sounds like a
> > showstopper though.
>
> There's a bunch of places where this is a problem.  This is a problem
> anywhere you want to add functionality to something that doesn't belong
> to you.  The effects of imports is a problem -- but it's a problem we
> already have, not one that is added just with generic functions or
> adaptation.

(Generally, I'm going to keep out of this, but I want to comment on
this one point).

Showstopper is a bit strong. At worst, import-for-side-effect it's bad
style, but it's not a requirement of generic functions (or of
adaptation, for that matter, where much the same registration issue
applies).

If you are defining a new class, and want to include pretty-printing
support, you'd include the generic function in the module which
defines the class. So the import is not "just for side effect", it
exports the class itself.

If you're an application writer who wants to use an existing class
with pprint, but that class doesn't support pretty-printing, you need
to write the plumbing (generic function instance) and register it.
That's all application code, and how you structure it is up to you.
You could have a module that is just imported for effect, but I'd be
more likely to write a wrapper module round the module which exported
the class - it imports the class, adds the generic functions needed
for your application, and re-exports the class. Then you import your
ONE module defining the "enhanced" class, rather than importing TWO
modules - the original module to get the class, and a "magic" module
to add behaviour.

But ultimately, it's your choice how you organise your code. All I'm
saying is that imports for side effect are *not* required with generic
functions or adaptation.

Paul.