-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
Method Resolution Order (MRO) is not compliant #525
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Unfortunately, those links don't give complete truth, because:
One would expect tuple's print to be used if real natural ordering is used. What logic CPython applies here? That builtin type's print used only if no user types provide it? (Supposedly to let user chance override it?) Is it applied only for special methods (like |
And that's exactly MRO non-compliance what hits: |
Righto. Well, if it's supposed to be that way, then it's going to be a hack to implement. |
Seems that Also seems that explicit |
And yet |
@dpgeorge , as reply to python-dev message above explains, this case is fully governed by C3 MRO algo. Then apparently CPy for a case where We surely don't need to either implement or emulate this |
I get:
|
Yup, my "apparently" is based on watching that. |
Also, constructor resolution is a somewhat special matter, but I'll elaborate in #401. |
Well, at least this means we can go ahead with a straight forward implementation of MRO, and get these details correct at the very end, if at all. |
uPy currently implements depth-first MRO, which is equivalent to one used pre-Python2.2.
References:
The text was updated successfully, but these errors were encountered: