On 01/07/15 03:48, Ben Finney wrote:
Alan Gauld 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 and call a method directly
how is the MRO involved in that invocation? (It is involved
if the method is actually implemented in a super-superclass
of course, I understand that bit.) But how does MRO affect
a direct call to a method of a class?
It's explicitly single inheritance and they are explicitly calling the
superclass.
They don't know that the superclass will be what is written there;
that's an implication of what I said with “in Python, any class an
participate in multiple inheritance”.
If MyList is included in a MI lattice that doesn't change the fact that
MyList inherits directly from list. Or at least I hope not, that could
be catastrophic to the behaviour of the class. The class definition
demands that MyList has a single direct superclass (and potentially many
super-super-classes). that is the very basis of the Is-A relationship
that inheritance indicates.
The author of a class (e.g. the OP's example ‘MyList’) cannot know at
time of writing whether the superclass is ‘list’. This is because some
other class may be using ‘MyList’ in a different inheritance
arrangement.
That should not change the superclass of MyList. It just means that
the new subclass doesn't know where list appears in the execution
order of its superclass calls. But it should not change the behaviour of
MyList methods.
Even without either party (the author of ‘MyList’, or the author of the
other class) intending it to be so, the MRO can run through ‘MyList’ in
a direction not specified by either author.
I'm not sure what you mean by 'direction' there?
But I agree neither author can tell where in the sequence of
method calls the MyLIst version will be called when the method
is invoked on the subclass. If that's what you mean?
Multiple inheitance is a fact in Python, and good practice is to not
arbitrarily write classes that break it.
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's critical to the use of MI in any language
The issues around that are addressed differently by different languages,
for example Eiffel allows you to rename inherited methods
or attributes to avoid them being used involuntarily. Most just allow
the programmer to explicitly access the superclasses where default
behaviour is not required. That's what I thought Python was doing with
super. Making default easy to get but still allowing direct overriding
when required.
Much as the class author might like it to be so simple, in Python it
just isn't so: any other class using multiple inheitance may pull in
this one, either as a parent or in some other indirect relationship.
Thus the above assertion is violated.
Not so. A single inheritance class, even in an MI scenario must still be
able to rely on its own superclass being the one stated. To do otherwise
would result in very weird and unpredictable behaviour.
In Python code it can't be said “there should be not MRO lookup at this
class level”. It's not for the class author to say whether some other
class “should not” inherit, directly or indirectly, from this and some
other class(es).
Yes, but then the MRO is invoked at that subclass level. Its not in the
power of the class author to know how the class will be used in future
class definitions. But the class *must* always follow the semantics of
the original class or the contract of the definition is broken.
class A(B,C,D):
def m(self):
C.m(self) # call C's m but not B and D if they have them.
Or am I missing something in the way Python evaluates
the C.m() call above?
I still want to know how you would code the above scenario
using super? If B,C and D all have an m() method but I only
want to call the version in C how do I control that in
Python other than by a direct call to C.m()?
My understanding comes from (among other places) the Python docs::
[…] dynamic ordering is necessary because all cases of multiple
inheritance exhibit one or more diamond relationships (where at
least one of the parent classes can be accessed through multiple
paths from the bottommost class). For example, all new-style classes
inherit from `object`, so any case of multiple inheritance provides
more than one path to reach `object`. […]
Yes I understand that. If you want to call all of the superclass
versions of a method you are overriding then super is the only way to
go. I'm talking about the case where you have a single superclass method
that you want to invoke.
As I understand it, MyList can still explicitly call list and, if in an
MI scenario, the list method can call super and it w
