Skip to content
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

Merged
merged 2 commits into from
Jan 15, 2020

Conversation

encukou
Copy link
Member

@encukou encukou commented Jan 14, 2020

  • 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).

cc @Dormouse759

- 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).
Copy link
Contributor

@ncoghlan ncoghlan left a 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
Copy link
Contributor

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
Copy link
Contributor

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.

@encukou
Copy link
Member Author

encukou commented Jan 15, 2020

Thanks!

It would be good to have a "Deferred Ideas" section explaining why the MRO walker concept was deferred.

I expanded the existing note in "Possible Future Extensions", hopefully that's OK even though it's something we really want to do.

@ncoghlan ncoghlan merged commit 2758332 into python:master Jan 15, 2020
@encukou encukou deleted the pep-573-mod-state-access-no-mro branch January 16, 2020 12:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants