<snip> > The problem of the MRO isn't that it doesn't work, it's that it causes > behavior that is unintuitive. In my example, We would expect D.x to be > equal to C.x (since D inherits from C, and C overrides the x method). > However, this is not the case. This is what the problem is with the > old MRO system, not so much that it doesn't work at all, but the > results aren't consistent with what you'd expect from multiple > inheritance. > > I tried your example in python2.6
>>> class A: ... def x(self): return "in A" ... >>> class B(A): pass ... >>> class C(A): ... def x(self): return "in C" ... >>> class D(B, C): pass ... >>> o = D() >>> o.x() 'in A' If MRO was in python2.3, the output of o.x() should be 'in C'. It works fine on 3.2alpha though. > I just found this link, where Guido explains why he changed the MRO > system for new-style classes. He uses the same example I do. > > http://www.python.org/download/releases/2.2.2/descrintro/#mro > > This was the only useful link I found upon googling. Thanks for your effort though.
_______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
