<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jul 5, 2018 at 3:06 PM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Thu., 5 Jul. 2018, 1:21 am Guido van Rossum, <<a href="mailto:guido@python.org" rel="noreferrer" target="_blank">guido@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div></div></blockquote><div><br></div><div>Would it be helpful if PEP 572 spelled out the translations of some common and corner cases? It's difficult to present a general rule for translating because of the required static analysis (not impossible but it would be low information density compared to the spec that's already there), but it might help clarify the spec for implementers who aren't from Mars.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div></div></blockquote><div><br></div><div>That sounds intriguing, but I can't easily get it to work. I get either "TypeError: globals must be a real dict; try eval(expr, {}, mapping)", when I pass that for globals, or the same error as before, "NameError: name 'a' is not defined", when I follow that advice and pass the ChainMap instance as the locals. Plus it(ironically, perhaps :-) it screws up the output of "p locals()".<br></div></div><br>-- <br><div dir="ltr" class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div></div>