[Python-Dev] Things to Know About Super

Michele Simionato michele.simionato at gmail.com
Fri Aug 29 06:07:27 CEST 2008


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. 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? How easy would be for an average framework user
to understand what is happening to his class?
I think class decorators would be a much better solution than
classy_class for most use cases and we should push that way,
not the cooperative inheritance way.

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.

           Michele Simionato


More information about the Python-Dev mailing list