-
-
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 667: Clarify specification ambiguities and the expected impact #3845
base: main
Are you sure you want to change the base?
Conversation
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.
This looks really good!
I think it might also make sense to add a "Rejected Alternatives" section, with a sub-section "Maintaining existing behavior of exec", discussing some of what we talked about in Discourse about the problems with trying to do this.
The new section looks good to me. FWIW, What's New in 3.13 does discuss this aspect of the change (https://docs.python.org/dev/whatsnew/3.13.html#defined-mutation-semantics-for-locals), but having more details in the PEP definitely won't hurt. |
It may also be worth referencing back to the PEP 558 discussions of the impact of changing the way
And while PEP 667's text didn't explicitly mention the impact on This is a case where the use of competing PEPs may have let us down a bit - PEP 667 (quite reasonably) didn't bother repeating the rationale for the aspects where it agreed with the design decisions in PEP 558, so reading it in isolation from PEP 558 doesn't quite give the full picture of the change. |
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.
So should I post this on disclosure first? |
Yes, this should be posted on Discourse to get community feedback, but it probably makes sense to address the existing feedback first? |
Co-authored-by: Carl Meyer <[email protected]>
Of course, just want to make sure about the procedure. I'm a bit swamped recently. |
I ticked the SC approval box in the template, since we have that in python/steering-council#245 (comment) |
I could be misunderstanding, but I don't see an indication in that comment that the SC considered the issue of |
Co-authored-by: Carl Meyer <[email protected]>
@gaogaotiantian I accepted @carljm's suggestions so that I could look at the prose as it would display to a reader. I am going to add a few suggestions re: grammar, and then I believe this will be acceptable from my viewpoint. Thanks so much for doing this. It adds important clarity for all. 💐 |
This PR mores than doubles the size of PEP 667. That seems excessive. The impact on """
Similarly, for All the extra history and exposition only serves to obscure the semantics, IMO. Fleshing the out the rationale a bit seems reasonable, but not too much. |
I had omitted Unfortunately, I don't see a neat way of expressing the semantics of It's possible to get the semantics correct using
However, I'll see how the code version looks in context, since I agree that precision is desirable here. Edit: the semantically correct code version ended up looking fine, so I included it in the specification section (it's also useful for anyone else wanting to emulate this argument handling in their own Python code): FrameProxyType = type((lambda: sys._getframe().f_locals)())
def eval(expression, /, globals=None, locals=None):
if globals is None:
# No globals -> use calling frame's globals
_calling_frame = sys._getframe(1)
globals = _calling_frame.f_globals
if locals is None:
# No globals or locals -> use calling frame's locals
locals = _calling_frame.f_locals
if isinstance(locals, FrameProxyType):
# Align with locals() builtin in optimized frame
locals = dict(locals)
elif locals is None:
# Globals but no locals -> use same namespace for both
locals = globals
return _eval(expression, globals, locals) (Related: it's unfortunate it is too late in the release cycle to add a I agree the extra words in the backwards compatibility section aren't useful to implementers, but I do think they're potentially useful to regular Python users bitten by the change to make |
* exec/eval semantics should be clearly specified * proxies do not fully implement MutableMapping
Given that the last 3.13 beta is behind us with |
Co-authored-by: Petr Viktorin <[email protected]>
I finally worked out a good way to simultaneously resolve both my concerns with providing a clear explanation of why we made Edit: content has been split, so the PEP 558 changes have been merged in https://github.com/python/peps/pull/3895/files |
especially the :ref:`pep-558-motivation` section and :ref:`pep-558-exec-eval-impact`. | ||
|
||
This approach is not without its drawbacks, which are covered | ||
in the Backwards Compatibility section below. |
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.
Missing pieces to get the PR merged:
- agreement from @markshannon that enough of the PR content has been moved over to PEP 558 for the rest to be acceptable (and what should be removed if the PR is still too big)
- confirmation from the SC that they're happy the missing impact assessment has now been added
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.
The SC is happy with the new text and has no suggestions or requests for any additional changes.
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.
Given the SC approval, I filed an issue for adding the hard deprecation to PyEval_GetLocals()
for 3.14: python/cpython#125170
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.
@markshannon can you approve?
PEP 123: Summary of changes
)📚 Documentation preview 📚: https://pep-previews--3845.org.readthedocs.build/