-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
PEP 573: Remove DefiningTypeFromSlotFunc, split public/private API #1275
PEP 573: Remove DefiningTypeFromSlotFunc, split public/private API #1275
Conversation
- Remove the MRO walker, PyType_DefiningTypeFromSlotFunc, as it was found it can give wrong results when a type's special methods are changed (which can be done from Python code). Solving the issue is deferred to a future PEP (and/or perhaps a private CPython function). - Split public C-API from CPython implementation details. It turns out that alternate C-API implementations have grown more important since 2016, if only for experimenting with possible optimizations. - Add potentially confusing terms "Defining Class" and "C-API" to the terminology section. - Mention that ht_module i not inherited by subclasses. - Remove modules to be ported initially: zipimport (since rewritten in Python), _io and _cvs (need module state from slot methods).
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.
It would be good to have a "Deferred Ideas" section explaining why the MRO walker concept was deferred.
pep-0573.rst
Outdated
from slot methods (``nb_add``, etc) remains slower than accessing that state | ||
from other extension methods. Standard caching techniques can be used to speed | ||
up subsequent access. | ||
remaining concerns. In particular, at access to the module state |
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.
Left over "at"
pep-0573.rst
Outdated
``True.__floor__`` and ``int.__repr__``. | ||
|
||
(For methods defined in Python, where unbound methods are plain functions, | ||
the term is somewhat fuzzy. This PEP deals with methods defined in C |
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.
It isn't normally fuzzy in Python - it's what ends up in the __class__
closure cell.
Thanks!
I expanded the existing note in "Possible Future Extensions", hopefully that's OK even though it's something we really want to do. |
found it can give wrong results when a type's special methods are
changed (which can be done from Python code).
Solving the issue is deferred to a future PEP (and/or perhaps a
private CPython function).
that alternate C-API implementations have grown more important
since 2016, if only for experimenting with possible optimizations.
terminology section.
in Python), _io and _cvs (need module state from slot methods).
cc @Dormouse759