[Python-Dev] Things to Know About Super

[Phillip J. Eby]

At 06:07 AM 8/29/2008 +0200, Michele Simionato wrote:
>On Thu, Aug 28, 2008 at 8:54 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> > I created a "universal metaclass" in
> > DecoratorTools whose sole function is to delegate metaclass __new__,
> > __init__, and __call__ to class-level methods (e.g. __class_new__,
> > __class_call__, etc.), thereby eliminating the need to have custom
> > metaclasses for most use cases in the first place.  Now, wherever possible,
> > I use that single metaclass in my frameworks, so that there's no 
> need to mix
> > them.
>
>easy_installed DecoratorTools and found it: classy_class.
> >From the point of view of the code, this is a beautiful and elegant
>snippet. However, suppose that from tomorrow everybody starts
>using it. Since metaclasses would become so easy to use, possibly a
>lot of people would take advantage of them.

That was sort of the idea.  ;-)

>  Then we would have
>potentially complex (multiple) inheritance hierarchies with
>chains of methods (_class__new__/_class__init__) calling
>themselves cooperatively in the MRO. Would the resulting
>code be readable?

Readability's orthogonal.  Some of them might be readable, some 
not.  Depends on who's writing them.  :)


>How easy would be for an average framework user
>to understand what is happening to his class?

You're right, let's abolish inheritance, too, because then you might 
have to read more than one class to see what's happening.


>I think class decorators would be a much better solution than
>classy_class for most use cases

Obviously, I disagree.  :)  You'll notice that DecoratorTools 
supports class decorators for Python 2.3 and up (actually, I think 
that particular bit worked in 2.2 as well).  So, it's not the absence 
of class decorators that motivated the 'classy' mixin.


>Generally speaking I like
>more solutions bases on functional composition (as in WSGI
>that you know very well) than on method cooperation. Rather than
>improve the support for inheritance, I would like (in an ideal
>world) to reduce it, to make easier the choice for people between
>inheritance and alternatives (object composition, delegation, functional
>composition). In the real world, I am content in documenting the
>pitfalls of super, warn people about the dangers of complex
>design involving multiple inheritance and cooperation, and suggest
>alternatives.

Naturally, if you can design a system to use delegates instead of 
class hierarchy to represent a chain of responsibility, it might well 
be an improvement.  But there are tradeoffs, and no matter what you 
are going to end up coding chains of responsibility.  Co-operative 
inheritance is a nice solution for chains of responsibility that can 
be expressed in a class hierarchy, and are no more "dangerous" than 
any other sort of chain of responsibility.  In fact, they are in some 
ways less so since the patterns are likely to be better documented 
than anything you come up with on your own.