[Python-Dev] Things to Know About Super

[Phillip J. Eby]

At 05:50 PM 8/28/2008 +0200, Michele Simionato wrote:
>On Aug 28, 5:30 pm, "Phillip J. Eby" <p... at telecommunity.com> wrote:
> > How is that making things easier for application programmers?
>
>We have different definitions of "application programmer". For me a typical
>application programmer is somebody who never fiddles with metaclasses,
>which are the realm of framework builders.

Application programmers use frameworks, and sometimes more than 
one.  If they're subclassing from two different frameworks, each 
using a different metaclass, they will need to also multiple-inherit 
the metaclass.

This is in fact so annoying that 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.

That, IMO, would be a more useful change than getting rid of super(); 
it would get rid of the explicit metaclass mixing.  (It would still 
not remove the need for co-operative methods, as the class-delegated 
methods still need to be co-operative for MI to work.)

There are, of course, other ways to create co-operative function 
calls besides super(), and I've certainly created more a few of them 
in my time.  (E.g. generic function method combination, 
instancemethod() chains, and next-method-iterators, to name the ones 
that occur to me right off.)  But these are more for cases where 
super() is wholly inadequate to the purpose, and none are anywhere 
near as convenient as super().