← 返回首页
gh-74929: Rudimentary docs for PEP 667 by gvanrossum · Pull Request #118581 · python/cpython · GitHub
Skip to content

Navigation Menu

Toggle navigation
Sign in
Appearance settings
Search or jump to...

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Resetting focus

gh-74929: Rudimentary docs for PEP 667#118581

Merged
gvanrossum merged 5 commits into
python:mainfrom
gvanrossum:whatsnew-f-locals
May 5, 2024
Merged

gh-74929: Rudimentary docs for PEP 667#118581
gvanrossum merged 5 commits into
python:mainfrom
gvanrossum:whatsnew-f-locals

Conversation

gvanrossum commented May 4, 2024
edited
Loading

Copy link
Copy Markdown
Member

This is not sufficient for the final 3.13 release, but it may have to do for beta 1:

  • What's new entry
  • Updated changelog entry (news blurb)
  • Mention the proxy for f_globals in the datamodel and Python frame object docs

This doesn't have any C API details (what's new refers to the PEP).

For some reason I cannot get the "versionchanged" note in the datamodel docs to show. @hugovk ?

📚 Documentation preview 📚: https://cpython-previews--118581.org.readthedocs.build/

Comment thread Doc/reference/datamodel.rst Outdated Show resolved Hide resolved
gvanrossum requested a review from AlexWaygood May 4, 2024 20:50

Copy link
Copy Markdown
Member

There's a minor technicality here that might worth clarification.

import sys frame1 = [sys._getframe() for a in [0]][0] frame2 = sys._getframe() assert frame1 is frame2 local1 = [sys._getframe().f_locals for a in [0]][0] local2 = sys._getframe().f_locals assert local1 != local2

Whether f_locals is a proxy or a dict technically does not entirely depend on the frame. It depends on when is the frame.f_locals call made - inside a comprehension or not.

As you can tell from the example above, the frame is exactly the same frame object, but the f_locals is different.

Copy link
Copy Markdown
Member Author

There's a minor technicality here that might worth clarification. [...]

That's very subtle. Is it explained in PEP 667? I'm not sure how to work this in the existing (pretty sparse) docs for f_locals.

Copy link
Copy Markdown
Member

Actually the final behavior we agreed on is slightly different from what PEP 667 proposed. PEP 667 also did not mention how f_locals should work with inline comprehensions. Can we modify PEP 667 after it was accepted? I don't know if we should dump all the details in the f_locals docs because it would be rare for the users to use f_locals inside the comprehension so no need to confuse them, but it would be nice to explain it well in PEP 667.

Copy link
Copy Markdown
Member Author

Actually the final behavior we agreed on is slightly different from what PEP 667 proposed. PEP 667 also did not mention how f_locals should work with inline comprehensions. Can we modify PEP 667 after it was accepted? I don't know if we should dump all the details in the f_locals docs because it would be rare for the users to use f_locals inside the comprehension so no need to confuse them, but it would be nice to explain it well in PEP 667.

Assuming this is about clarifying something that the original text of the PEP did not specify precisely enough, and given that the PEP is brand new, I think it's okay to clarify in the PEP. Although in general PEPs are nowadays seen as historic documents, not as living specifications.

AlexWaygood commented May 4, 2024
edited
Loading

Copy link
Copy Markdown
Member

It's not something that has to be done in this PR, but if we think that there are some subtleties here that warrant detailed explanation and that the datamodel docs aren't the right place to do that, one option would be to add a howto similar to the one Larry added in 3.10 to explain the semantics of the __annotations__ attribute: https://docs.python.org/3/howto/annotations.html

It wouldn't really be a howto in the Diataxis sense of the term, but we don't really have a better place for that kind of in-depth article in the CPython docs currently, and there are lots of other articles in that directory that also don't meet Diataxis's strict definition of a "howto" article. And as @gvanrossum says, all the relevant information regarding the semantics here should ideally be findable in the CPython docs somewhere, without having to refer to the PEP, which is a historical document now that it has been accepted.

(But we can probably update the PEP as well, given that it's only just been accepted :-)

Copy link
Copy Markdown
Member Author

@AlexWaygood @gaogaotiantian Are you two okay with me merging this? I'm all for iterating later, but I feel it's important to mention at least this much in the beta 1 docs, which I expect will reach a relatively big audience of people who are thinking of testing the beta.

Copy link
Copy Markdown
Member

Yes this feels okay for beta.

Comment thread Doc/whatsnew/3.13.rst

* :pep:`667`: :attr:`FrameType.f_locals <frame.f_locals>` when used in
a function now returns a write-through proxy to the frame's locals,
rather than a ``dict``. See the PEP for corresponding C API changes

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment
Suggested change
rather than a ``dict``. See the PEP for corresponding C API changes
rather than a :class:`dict`. See the PEP for corresponding C API changes

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

I think that would be a case of over-linking. Surely readers who know what f_locals is will be familiar with dict.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

Sure, I don't feel strongly, feel free to ignore

Comment thread Misc/NEWS.d/next/Core and Builtins/2024-04-27-21-44-40.gh-issue-74929.C2nESp.rst Outdated Show resolved Hide resolved
Comment on lines +1345 to +1349
If the frame refers to a function or comprehension,
this may return a write-through proxy object.

.. versionchanged:: 3.13
Return a proxy for functions and comprehensions.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

And apparently this also applies for type parameter scopes? Though I have no idea if that was deliberate:

>>> import sys >>> type T[X: type(sys._getframe().f_locals)] = ... >>> T.__type_params__[0].__bound__ <class 'FrameLocalsProxy'>

gvanrossum enabled auto-merge (squash) May 5, 2024 15:16
gvanrossum merged commit 9c13d9e into python:main May 5, 2024
gvanrossum deleted the whatsnew-f-locals branch May 5, 2024 18:47
SonicField pushed a commit to SonicField/cpython that referenced this pull request May 8, 2024
This is *not* sufficient for the final 3.13 release, but it will do for beta 1: - What's new entry - Updated changelog entry (news blurb) - Mention the proxy for f_globals in the datamodel and Python frame object docs This doesn't have any C API details (what's new refers to the PEP).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs Documentation in the Doc dir

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

Footer

© 2026 GitHub, Inc.