Skip to content

PEP 667: add 709 impact, other tweaks #3196

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

Merged
merged 2 commits into from
Aug 2, 2023
Merged

Conversation

carljm
Copy link
Member

@carljm carljm commented Jul 11, 2023

A few proposed updates to PEP 667. Namely:

  • Add a brief section on interaction with PEP 709 inlined comprehensions. Contrary to gh-105340: include hidden fast-locals in locals() cpython#105715 (comment), I don't think that we need to, or should, make frame.f_locals be a proxy in module or class scopes. In particular, making locals() always return a new snapshot (rather than the true persistent locals dict) in module or class scopes would be too large a back-compat break, I think, since people may be currently relying on assignment to locals() in those scopes. Instead I think we can simply preserve the current (3.12) behavior that locals() returns a new snapshot dict in module/class scope only when inside an inlined comprehension. This PEP makes that behavior consistent with how locals() works inside functions, so in effect it preserves the fiction that a comprehension is a function, even though it is inlined.
  • Add the clarification requested in https://discuss.python.org/t/pep-667-question-about-impact-on-function-local-variable-lookup/17804 about keys added to f_locals that are not local variables.
  • A few other minor fixes.
  • Add a Python-Version header, targeting this PEP to 3.13, and update deprecations to be removed in 3.15, not 3.14.

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

@carljm carljm requested a review from markshannon as a code owner July 11, 2023 00:38
@carljm
Copy link
Member Author

carljm commented Jul 11, 2023

cc also @ambv

@carljm
Copy link
Member Author

carljm commented Jul 12, 2023

Oops, first version of this PR had a couple changes that were based on mistakenly assuming frame->_locals_cache would be a real dictionary, not a proxy mapping. I've reverted those changes in this PR (and edited the description accordingly.)

I do wonder if it might be better from a backwards-compatibility perspective to keep PyEval_GetLocals() behaving as before and returning a dictionary, rather than returning a proxy mapping, and let C extension authors opt in to the new semantics by switching to the new functions. But that discussion should be separate from this PR.

@markshannon markshannon merged commit d5e12f5 into python:main Aug 2, 2023
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