<div dir="ltr"><div>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.</div><div><br></div><div>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:</div><div><br></div><div><span style="font-family:monospace,monospace">(Pdb) p [getattr(context.context, x) for x in dir(context.context)]<br>*** NameError: name 'context' is not defined<br>(Pdb) global cc; cc = context<br>(Pdb) p [getattr(cc.context, x) for x in dir(cc.context)]</span></div><div><span style="font-family:monospace,monospace">[<class 'mypy.nodes.CallExpr'>, ............]<br></span></div><div><span style="font-family:monospace,monospace">(Pdb)</span></div><div><br></div><div>The first attempt failed because the outer `context` was a local variable in some function, and pdb uses eval() to evaluate expressions.<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 4, 2018 at 5:36 AM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">With PEP 572's formal acceptance now expected to be just a matter of<br>
time, I'll limit any further personal expressions of opinion on the<br>
change and the process taken to achieve it to other venues :)<br>
<br>
However, there's a design aspect I do need to address, which is to<br>
make sure that PEP 558 (my proposal to actually nail down an<br>
implementation independent specification for how we expect locals() to<br>
behave at runtime) accurately covers the way runtimes and debuggers<br>
are expected to behave when comprehensions and generator expressions<br>
are executed at different scopes.<br>
<br>
My current view is that it's going to be OK to expose the differing<br>
behaviours at module and function scope directly:<br>
<br>
* if you debug a module level comprehension or genexp, the target name<br>
will be flagged on the code object as a dynamically resolved name<br>
reference, so a debugger should handle it the same was as it would<br>
handle any other "global NAME" declaration (and it will appear only in<br>
globals(), not in locals())<br>
* similarly for a function comprehension or genexp, the name will show<br>
up like any other "nonlocal NAME" (appears in locals() rather than<br>
globals(), and is affected by the proposed changes in the interaction<br>
between trace functions and the frame.f_locals attribute)<br>
<br>
I think that's an acceptable outcome, since it's a natural consequence<br>
of PEP 572 defining its comprehension and generator expression<br>
handling in terms of existing global and nonlocal scoping semantics.<br>
<br>
Cheers,<br>
Nick.<br>
<br>
-- <br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>