Multiple inheritance, super() and changing signature
Nagy László Zsolt
gandalf at shopzeus.com
Fri Jun 3 08:10:22 EDT 2016
> In Python 3, that will be automatic and you don't need to worry about it.
I'm using Python 3. I'm aware of old style and new style classes in
>> class BootstrapDesktop(BootstrapWidget, BaseDesktop):
>> def __init__(self, appserver, session):
>> # there is NOTHING else here, it just connects bootstrap widget
>> implementation with desktop methods
>> super(BootstrapDesktop, self).__init__(appserver, session)
> The correct way to do that is to simply not define an __init__ method at
But I have to initialize some default attributes. I could put them into
a method called something else, but that would have the same problem.
The question I put up is not specific to constructors, initializers or
whatever. It was a general question about super() being used in a
hierarchy with different signatures of the same method. I'm not sure why
everybody started to discuss __init__ and __new__ :-)
> Raymond Hettinger gives an excellent presentation where he describes various
> problems with MI and gives solutions for them. I think this might be it:
I'm going to get back when I'm done with this video. It will take some
>> There is a single class (Widget) that has changed the signature of the
> Is this your code? Then simply fix Widget. MI in Python is cooperative: all
> the classes have to be designed for MI. It seems that Widget is not.
> (Possibly I have misdiagnosed the problem, and the fault lies elsewhere.)
If I knew what would be a good fix, I would do it. Somebody else
suggested to always use *args and **kwargs. That would be cooperative
for sure. But then It would be much harder to document the code (with
Sphinx for example), or use the syntax analyzer of an IDE (say PyCharm)
and have code completion. (Although the later is not a good argument
against the language itself.)
> Even if you got your wish, you couldn't use it until you're using Python 3.6
> or higher.
Yes, I know. I do this for fun, not for money.
> That's overly strict. As Raymond shows, it is easy to deal with
> changing method signatures in *cooperative* classes.
I must watch that for sure.
> Perhaps you are unaware that manually calling the superclass method does not
> work correctly in cases of multiple inheritance? You end up either missing
> classes, and not calling their method, or calling them twice. That's why
> you need to use a proper linearisation algorithm, as used by super.
> See this explanation of C3 linearisation here:
I do not use diamond shapes in my hierarchy, I guess that does not
affect me. I may be wrong.
More information about the Python-list