[Python-Dev] Breaking calls to object.__init__/__new__

[Phillip J. Eby]

At 09:41 PM 3/21/2007 -0700, Guido van Rossum wrote:
>On 3/21/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> > Every time I've considered using super, I've eventually
> > decided against it for reasons like this. I've always
> > found a better way that doesn't introduce so may
> > strange interactions between the classes involved.
>
>I end up feeling the same way, for purely pragmatic reasons. However,
>cooperative multiple inheritance is a respected religion, and when
>practiced systematically can work well.
>
>Also make a big distinction between super calls of __init__ (which are
>a Pythonic wart and don't exist in other languages practicing multiple
>inheritance AFAIK) and super calls of regular methods (which are
>virtually problem-free as long as you agree on a base class that
>defines a method and derive from that class when you want to extend
>it).

FYI, the only time I ever use super() for __init__ calls is for 
metaclasses.  However, there the signature is fixed, so this problem 
doesn't really arise.

However, in Py3K the metaclass __init__ will accept keyword 
arguments.  What's the right thing to do there?  Should we pass them all 
through?

I'm not sure if there's any inherent symmetry between this and 
object.__init__ -- but it seems to be an interesting question in its own right.

The whole point of being co-operative in a metaclass is to allow other 
metaclasses to be safely mixed in -- and they may be metaclasses from a 
completely different library or framework.  So, it's not as simple as 
saying "use a specialized base class" -- the class author may not even 
*know* that metaclasses are involved, let alone multiple ones.