(original) (raw)
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)\]
\*\*\* NameError: name 'context' is not defined
(Pdb) global cc; cc = context
(Pdb) p \[getattr(cc.context, x) for x in dir(cc.context)\]
\[, ............\]
(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@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@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)