[Tutor] Inheritance, superclass, ‘super’

[Oscar Benjamin]

On 3 July 2015 at 00:47, Ben Finney <ben+python at benfinney.id.au> wrote:
>> That depends on what you mean by break it., MI should allow the
>> inheriting class to specify which, if any, of its direct superclasses
>> methods are invoked.
>
> That “should” is contrary to Python's collaborative multiple inheritance
> model. Instead, multiple inheritance in Python entails that any class
> should allow the methods of the same name, in all superclasses of this
> one, to execute in the sequence determined by ‘super’.
>
> So, if you want behaviour as you describe there, you want something that
> Python's mutliple inheritance explicitly won't give you.

I guess you mean something that it won't *implicitly* give you. Python
makes it possible to construct whatever method dispatch system you
like in MI but super is designed with the implicit intention that you
would use this particular convention that the same method is called in
all superclasses.

The particular model of multiple inheritance for which super is
designed requires the classes involved to have been designed for that
use case. Simply using super instead of explicitly invoking the
expected superclass does not make a class suitable for this or any
other MI method-calling convention. It is a necessary but not
sufficient condition to make it suitable for the convention you
describe.

You seem to be advocating that "everyone should always use super()
because everyone should always assume that someone else will want to
use their class in a particular style of multiple inheritance setup."
I would rather say that "no one should ever use classes in multiple
inheritance unless the classes involved were designed for that usage
together." (The everyone/always etc. are meant loosely.)

I guess a different point is that it's not really harmful to just use
super() so you may as well "just do it" without giving it much
thought. This argument makes more sense in Python 3 than Python 2
though since 2's super is a little tricky to get right in some cases
(e.g. __new__).

--
Oscar