Alan Gauld <alan.ga...@btinternet.com> writes: > On 01/07/15 03:48, Ben Finney wrote: > > Alan Gauld <alan.ga...@btinternet.com> writes: > > > >> Whilst I agree with the general use of super I'm not sure what > >> the MRO resolution has to do with this case? > > > > When accessing the superclass, the MRO is always relevant > > Can you explain that? > If I access a class explicitly
As explained on other posts: You're not getting “the superclass” if you do that. Knowing what the superclass is requires run-time determination of the MRO. > If MyList is included in a MI lattice that doesn't change the fact > that MyList inherits directly from list. Correct. The distinction being drawn here is between “the class from which MyList directly inherits” versus “the superclass of this class”. They are not the same, in multiple inheritance. To refer to the direct parent class, yes it's simple enough to hard-code that. But that's not the same thing as accessing the superclass, which must be determined at run-time. > 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. -- \ “Intellectual property is to the 21st century what the slave | `\ trade was to the 16th.” —David Mertz | _o__) | Ben Finney _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
