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

[Guido van Rossum]

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.f_locals 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>