[Python-Dev] Fw: MRO 2.2 vs 2.3

[Robin Becker]

In message <200210062027.g96KRwh28684 at pcp02138704pcs.reston01.va.comcast
.net>, Guido van Rossum <guido at python.org> writes
......
>
>If it's any consolation to you, you'd have to write a program with a
>pretty, um, "wild and wonderful" inheritance lattice before this would
>ever bite you.  It's also the case the the difference between the
>current algorithm and C3 is pretty small; the biggest difference is
>that in some extreme cases, when you write

Its precisely this small set of differences that make this seem more
like a bugfix than a new improved feature. 

I got the impression from lurking on the discussion that this new
behaviour was intended and not achieved. Personally I found the
reasoning about why one should do the extended precedence thing
extremely tenuous as it seems to be based on assertions about programmer
expectation. It's hard to believe that many can do high order graph
analysis by inspection of the terminal node order.

Does this new thing preserve current behaviours when adding more
subclasses ie 

B(A0,A1,...,Ak)
C(A0,A1,....Ak,Ak+1)

is it possible to say easily what happens?
>
>  class C(A, B): ...
>
>B may precede A in C.__mro__ with the 2.2 algorithm, but not with the
>C3 algorithm.  (The paper about C3 referenced by descrintro.html has
>some examples; in all the examples that I've verified, the 2.2
>algorithm behaves the same as L*LOOPS in the paper, even though
>Samuele has constructed an example where L*LOOPS is different again:
>this is due to the fact that L*LOOPS merges all lists simultaneously,
>while the "conservative merge" algorithm in 2.2 can only merge two
>lists at a time.
>
>--Guido van Rossum (home page: http://www.python.org/~guido/)
>

-- 
Robin Becker