[Python-Dev] Breaking calls to object.init/new (original) (raw)

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 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.

More information about the Python-Dev mailing list