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 <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ > Python-Dev mailing list > Python-Dev@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)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com