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 +--------------------------------------+
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4