Thanks to visit codestin.com
Credit goes to github.com

Skip to content

PEP 788: Address feedback from first discussion round #4400

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

Open
wants to merge 27 commits into
base: main
Choose a base branch
from

Conversation

ZeroIntensity
Copy link
Member

@ZeroIntensity ZeroIntensity commented May 3, 2025

  • Change is either:
    • To a Draft PEP
    • To an Accepted or Final PEP, with Steering Council approval
    • To fix an editorial issue (markup, typo, link, header, etc)
  • PR title prefixed with PEP number (e.g. PEP 123: Summary of changes)

The key changes I made here are:

  • Interpreter references now have a dedicated type (PyInterpreterRef and PyInterpreterWeakRef *).
  • Add PyThreadState_GetDaemon() and what needs to happen to threading for that to work.
  • Add a terminology section for clarification on what things like "finalization" refer to in the PEP.
  • Add a rejected idea for the previous approach (mainly using PyInterpreterState * for refs).
  • Add an open issue for PyThreadState_Ensure stealing a strong reference.
  • Editorial: Lots of clarity fixes (many had trouble understanding the PEP, unfortunately).
  • Editorial: Headings are now in title case ("The Apple is Weird and Confusing") rather than sentence case ("The apple is weird and confusing").

📚 Documentation preview 📚: https://pep-previews--4400.org.readthedocs.build/pep-0788/

@ZeroIntensity ZeroIntensity marked this pull request as ready for review May 4, 2025 17:55
@ZeroIntensity ZeroIntensity requested a review from vstinner as a code owner May 4, 2025 17:55
@ZeroIntensity
Copy link
Member Author

@godlygeek I can't add you as a reviewer, but I'd appreciate your opinion on some of the new things I'm proposing here.

@ZeroIntensity ZeroIntensity requested a review from AA-Turner May 4, 2025 20:02
@ZeroIntensity
Copy link
Member Author

Bump @AA-Turner @vstinner now that the beta is out. There's no rush considering we have a year until the 3.15 freeze, though.

Return a strong reference to an interpreter from a weak reference.

If the interpreter no longer exists or has already finished waiting for
non-daemon threads, then this function returns ``0``.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same remark than PyInterpreterState_AsStrong(), I would prefer an API like: int PyInterpreterWeakRef_AsStrong(PyInterpreterWeakRef *wref, PyInterpreterRef *ref).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's probably harder to use, though.

ZeroIntensity and others added 3 commits May 9, 2025 07:21
Co-authored-by: Victor Stinner <[email protected]>
Co-authored-by: Victor Stinner <[email protected]>
@vstinner
Copy link
Member

vstinner commented May 9, 2025

I'm not comfortable with PyInterpreterRef and PyInterpreterWeakRef which are different: PyInterpreterRef is used as a scalar value, whereas PyInterpreterWeakRef is used as a pointer. I would prefer that both are scalars, or both are pointers. Maybe using a pointer API would be more future proof and it makes sure that the value (the pointer) can be stored ... in a pointer, for a callback argument.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants