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
Implement PEP560 inheritance (__mro_entries__) #4005
Conversation
Fixes cython#3537 Both the C code and the tests are largely copied from CPython so hopefully should be pretty reliable. This doesn't backport perfectly so I've hard to disable a few tests of Python 2 (and may have to on earlier Python 3 versions too). I think that's OK. I haven't applied this at all to cdef classes. Maybe it could be applied to the second+subsequent bases but I don't think it's needed for the initial implementation.
Changed
The failures are the same as master (unless I broke it with the current lot of changes...)
#4006 clears up some simple bugs one of the tests for in 2.7 and 3.4/3.5 I think. The C++ tests are largely failing because something changed in Pythran (but I don't think there's a good fix for that yet...) But I think there's a few other things too |
Cython/Compiler/Nodes.py
Outdated
| def analyse_expressions(self, env): | ||
| if self.bases and not (self.bases.is_sequence_constructor and len(self.bases.args)==0): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe not for this PR, but I wonder if we need to handle the "empty tuple" case at all. Isn't that something we can normalise away?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've not made any changes here.
As far as I can tell the self.bases check never fails (even for classes with no bases it's always assigned to an empty tuple). Therefore, I think that could go in principle (from both this and from existing code). It's possible I've missed a corner-case where it's useful though.
Explicitly handling an empty tuple is just a small optimization. We don't need to do it though - there's no issue with passing an empty tuple to __Pyx_PEP560_update_bases.
Co-authored-by: scoder <stefan_ml@behnel.de>
| @@ -4762,6 +4762,7 @@ class PyClassDefNode(ClassDefNode): | |||
| metaclass = None | |||
| mkw = None | |||
| doc_node = None | |||
| orig_bases = None | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also needs to be added to child_attrs to make sure it gets properly traversed. CloneNode blocks the traversal.
And please also document it in the comments above.
|
Thanks! |
Fixes #3537
Both the C code and the tests are largely copied from CPython
so hopefully should be pretty reliable.
This doesn't backport perfectly so I've hard to disable a few
tests of Python 2 (and may have to on earlier Python 3 versions too).
I think that's OK.
I haven't applied this at all to cdef classes. Maybe it could be
applied to the second+subsequent bases but I don't think it's
needed for the initial implementation.