QUERY · ISSUE

Method Resolution Order (MRO) is not compliant

openby pfalconopened 2014-04-28updated 2024-08-28

py-core

uPy currently implements depth-first MRO, which is equivalent to one used pre-Python2.2.
References:

http://python-history.blogspot.com/2010/06/method-resolution-order.html
https://www.python.org/download/releases/2.3/mro/

CANDIDATE · ISSUE

To support multiple inheritance, should filter out "object" from base class spec and handle it as implicit fallback

closedby pfalconopened 2014-05-22updated 2022-06-23

bug

We're not going to get proper Python MRO any time soon (#525), but to at least not break multiple inheritance (MI) in obvious way, we should at least do following:

Filter out "object" from any explicit base class specification. (turn class Foo(object) into class Foo).
Look up attributes in "object" as a fallback.

This will emulate the fact that in Python3, "object" is always the last type in MRO.

Failing to do the above may mean, that with our naive depth-first MRO, "object" ultimate base of first superclass in MI case may seize method call destined to another superclass, if "object" has such method. With #520 & #606, object now implements __new__ and __init__, so any other multi-superclass will be denied construction and initialization.

Assessment

S Sonnet · high

Issue #624 explicitly references #525 and acknowledges it as the root cause, but proposes a narrower workaround rather than resolving the underlying problem. #525 is the broad MRO compliance bug (depth-first vs C3 linearization). #624 targets one specific symptom: object intercepting method calls in multiple inheritance due to the naive depth-first MRO, and proposes filtering object from explicit base class specs as a stopgap. This does not fix the general C3 MRO non-compliance described in #525 — it only prevents one class of breakage. The two issues are clearly connected (same conceptual space, same root cause), but #624 does not resolve #525.

Suggested action

Keep both issues open. #624 should be cross-linked to #525 as a targeted workaround within the broader MRO compliance effort. If #624's specific fix (filtering `object` from base class specs) has been implemented, verify whether it was committed and close #624 as resolved; #525 should remain open until full C3 linearization is implemented.

Method Resolution Order (MRO) is not compliant

To support multiple inheritance, should filter out "object" from base class spec and handle it as implicit fallback

Keyboard