[Python-Dev] Checking that PEP 558 (defined semantics for locals()) handles assignment expressions
ncoghlan at gmail.com
Thu Jul 5 18:06:23 EDT 2018
On Thu., 5 Jul. 2018, 1:21 am Guido van Rossum, <guido at python.org> wrote:
> 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.
Cool. I'll still review the PEP to see if it makes sense to mention this as
a side note anywhere, but it may turn out to make more sense to simply not
mention it at all.
> 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'>, ............]
> The first attempt failed because the outer `context` was a local variable
> in some function, and pdb uses eval() to evaluate expressions.
Perhaps pdb should be passing something like "ChainMap(frame.f_locals,
frame.f_globals)" to the eval call as its global namespace when the current
frame uses optimized local variable references? That way even lexically
nested scopes inside the eval call will all be able to see the current
local variables via dynamic name lookup, even though they still won't see
them as lexical closure references.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev