[Python-Dev] Checking that PEP 558 (defined semantics for locals()) handles assignment expressions (original) (raw)

Guido van Rossum guido at python.org
Wed Jul 4 11:22:22 EDT 2018

Correct, there shouldn't be any additional corner cases for your PEP due to inline assignments. We're not introducing new scopes nor other runtime mechanisms; the target of an inline assignment is either a global or a cell (nonlocal) defined at a specific outer level.

What I wish we had (quite independent from PEP 572) is a way in a debugger to evaluate a comprehension that references a local in the current stack frame. E.g. here's something I had in a pdb session yesterday:

(Pdb) p [getattr(context.context, x) for x in dir(context.context)] *** NameError: name 'context' is not defined (Pdb) global cc; cc = context (Pdb) p [getattr(cc.context, x) for x in dir(cc.context)] [<class 'mypy.nodes.CallExpr'>, ............] (Pdb)

The first attempt failed because the outer context was a local variable in some function, and pdb uses eval() to evaluate expressions.

On Wed, Jul 4, 2018 at 5:36 AM Nick Coghlan <ncoghlan at gmail.com> wrote:

With PEP 572's formal acceptance now expected to be just a matter of time, I'll limit any further personal expressions of opinion on the change and the process taken to achieve it to other venues :)

However, there's a design aspect I do need to address, which is to make sure that PEP 558 (my proposal to actually nail down an implementation independent specification for how we expect locals() to behave at runtime) accurately covers the way runtimes and debuggers are expected to behave when comprehensions and generator expressions are executed at different scopes. My current view is that it's going to be OK to expose the differing behaviours at module and function scope directly: * if you debug a module level comprehension or genexp, the target name will be flagged on the code object as a dynamically resolved name reference, so a debugger should handle it the same was as it would handle any other "global NAME" declaration (and it will appear only in globals(), not in locals()) * similarly for a function comprehension or genexp, the name will show up like any other "nonlocal NAME" (appears in locals() rather than globals(), and is affected by the proposed changes in the interaction between trace functions and the frame.flocals attribute) I think that's an acceptable outcome, since it's a natural consequence of PEP 572 defining its comprehension and generator expression handling in terms of existing global and nonlocal scoping semantics. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org

-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180704/10e765e6/attachment.html>

More information about the Python-Dev mailing list