[Python-Dev] perplexed by mro

[Greg Ewing]

Guido:

> Now let's assume m is *also* overridden in a, so that y.m overrides
> a.m overrides object.m.  Now if we searched b before y (naive algo),
> it is arguably strange if the 'super' call chain went from y.m via b.m
> to a.m.

I don't understand that. According to the diagram I just
scribbled, the mro from the documented algorithm comes out as

  z, x, b, y, a, c, object

so the super chain would be b.m, y.m, a.m, object.m.

(Which is *also* wrong according to my intuition, by the way --
I would expect a super call inside b.m to go to object.m,
and not depend on z's inheritance structure -- but that's a
separate issue.)

Anyway, why not just use the algorithm you said you were
using in the docs -- i.e. traverse the inheritance hierarchy
and build the mro afresh each time, rather than trying to
merge the mro's of the superclasses.

If it's an issue of which algorithm is the one that should
be used, I vote for the documented one, because it's
simple and easy to explain! If it leads to odd things
happening in some cases, at least it's clear what odd
things will happen and why -- as opposed to other odd
things happening for mysterious reasons.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg@cosc.canterbury.ac.nz	   +--------------------------------------+