[Python-Dev] Breaking calls to object.__init__/__new__
Phillip J. Eby
pje at telecommunity.com
Thu Mar 22 05:53:24 CET 2007
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
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
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.
More information about the Python-Dev