Prev: Normalizing A Vector
Next: The untimely dimise of a weak-reference
From: Steven D'Aprano on 30 Jul 2010 07:49
On Fri, 30 Jul 2010 19:35:52 +1200, Gregory Ewing wrote:

> Steven D'Aprano wrote:
>
>> super() is just as explicit as len(), or str.upper(). It says,
>> explicitly, that it will call the method belonging to one or more
>> superclass of the given class.
>
> That's not strictly true. It will call a method belonging to some class
> in the mro of self, but that class is not necessarily in the base list
> of the class mentioned in the super() call.

Yes, that's what I said. super() can visit any superclass of the given
class, not just one of the immediate base class(es). That's why it's
called super() rather than base() or parent(). It would be rather
pointless if super() was limited to just the base classes.


> It's possible for a super()
> call to go "sideways" in the inheritance graph.

I doubt that very much. A class F can't inherit behaviour from a class E
merely by virtue of them both being subclasses of the same hierarchy. If
it did, that would be... disturbing.

Example:

E inherits from D.
D inherits from C and B.
C and B both inherit from A.
F also inherits from C.

F and E are "sideways" to each other (sibling classes?), but they don't
inherit from each other.

Perhaps you're referring to the angled lines in a diagram such as:

A
/ \
C B
\ /
D
/ \
E F

F and E don't inherit from each other, because they are sidewards to each
other (they are not in each other's MRO). Regardless of the angles we
draw the lines, all of D, C, B, A are above E (and F). Or downwards if
you prefer to reverse the diagram. Yes, a super call might jog left from
C to B, but only when being called from one of the lower classes D-F.
That's still an upwards call relative to the originator, not sidewards.



--
Steven
From: Steven D'Aprano on 30 Jul 2010 08:04
On Fri, 30 Jul 2010 19:37:29 +1200, Gregory Ewing wrote:

> Steven D'Aprano wrote:
>> On Thu, 29 Jul 2010 19:29:24 +0200, Jean-Michel Pichavant wrote:
> >
>>>"mro" would have been the proper name for "super".
>>
>> That's your opinion. In any case, whether super() was called super() or
>> mro() or aardvark() makes no difference to the functionality or whether
>> it is useful.
>
> I think the point is that the name is misleading, because it makes it
> *sound* like it's going to call a method in a superclass, when it fact
> it might not.

I'm not sure I understand your point here. If you call super() from a
method that doesn't exist in any superclass, then you are correct, it
won't call a method in a superclass, and will raise AttributeError.

But in the more sensible case that you only call super() when there is
actually something to inherit, then of course it calls the method in a
superclass. It certainly doesn't call methods from arbitrary unrelated
classes, only those which are in the MRO. That is, superclasses.

If Z is below A in the hierarchy, then we have no difficulty in
identifying Z as a subclass of A, and likewise we should have no problem
with identifying A as *a* (and not "the") superclass of Z, no matter how
distant they are or how tangled the DIG between them.

The exception would be if you could have loops in the class hierarchy, in
which case the concepts of super- and sub-classes breaks down completely.
But even if some other languages allowed that, Python doesn't, so we're
safe.



--
Steven
 | 
Pages: 1
Prev: Normalizing A Vector
Next: The untimely dimise of a weak-reference