On 3 July 2015 at 00:47, Ben Finney <ben+pyt...@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 _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
