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

Greg Ewing greg.ewing at canterbury.ac.nz
Thu Mar 22 04:45:24 CET 2007


Jean-Paul Calderone wrote:

> Perhaps I misunderstand the patch, but it would appear to break not just
> some inadvisable uses of super(), but an actual core feature of super().
> Maybe someone can set me right.  Is this correct?
> 
>   class Base(object):
>       def __init__(self, important):
>
> If so, what are the implications for this?
> 
>   class Other(object):
>       def __init__(self, important):

I think the idea was that each __init__ method *extracts*
the arguments that apply to it and doesn't pass them on.
Then, by the time object.__init__ is reached, there should
be none left.

This only works if the sets of keywords recognised by
each __init__ method are all disjoint.

Another approach is for none of them to extract anything,
and always pass everything on. Then you need something at
the top that accepts anything, and you get no error
checking.

This kind of thing seems to be a general feature of super,
i.e. in order for it to work properly, all the classes using
it have to agree on some set of rules or other. This creates
isolated ghettos of classes that can't be mixed with each
other. If you try to mix in a class which doesn't know about
the rules, or follows a different set of rules, everything
falls apart.

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.

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | Carpe post meridiem!          	  |
Christchurch, New Zealand	   | (I'm not a morning person.)          |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+


More information about the Python-Dev mailing list