[Python-3000] auto-super()

Greg Ewing greg.ewing at canterbury.ac.nz
Wed Apr 19 04:22:45 CEST 2006


Thomas Wouters wrote:

> The arguments against super() are 
> understandable -- if you only think about your own class, or completely 
> disregard MI. I think that's irresponsible: super() always calls the 
> right baseclass method,

On the contrary, it's precisely when you *don't* know
what classes are going be mixed in with you that super()
is likely to go haywire. Your super() call ends up
calling a method that you know nothing about, and
the method being called isn't expecting to be called
in that context either. Whether that will do the
"right" thing, or whether there even is a right thing
to be done, is anybody's guess.

What causes trouble isn't multiple inheritance, it's
diamond inheritance. Without diamond inheritance,
explicit calls to inherited methods usually work fine,
and continue to work fine when your classes get
inherited, multiply or otherwise, by other people's
classes, as long as they do something sensible with
their inherited calls.

Personally I think that the use of diamond inheritance
should be severely discouraged, if not banned completely.
There's a fundamental problem with it: different
subclasses can have different ideas on how the diamond-
inherited class should be initialised, and otherwise
used. That seems to me an inherent flaw in the notion
of diamond inheritance, and not something that super()
or anything else can fix.

Whenever I've tried to use diamond inheritance, I've
always ended up regretting it, and re-designing my class
hierarchy to eliminate it. Once I've done that, any
reason I had to use super() invariably disappears.

To put it another way, it seems to me that super() is
only there to try to work around problems introduced
by diamond inheritance, which IMO you shouldn't be
trying to use in the first place. That's why I regard
super() as a misfeature.

--
Greg



More information about the Python-3000 mailing list