<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">[Tim]</div><div dir="ltr"> > If the parent has a

matching parentlocal declaration for the same</div><div>> name then the original </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> really refers to the grandparent - and so on.<br></blockquote><div><br>[Greg] </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ah, I missed that part, sorry -- I withdraw that particular<br>
objecttion.<br></blockquote><div><br>Good!  I have another reply that crossed in the mail.<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Still, this seems like a major addition (seeing as it comes<br>
with a new keyword) whose justification is very little more<br>
than "it makes explaining comprehension scopes easier".<br><br></blockquote><div>I agree - it has no other sane use case I can see, and "parentlocal" isn't _needed_ to capture the intended semantics in by-hand translations of comprehensions.<br><br>I don't even think it makes "explaining" easier.  It doesn't eliminate any corner cases, it just pushes them into the definition of what "parentllocal" means.<br><br>What it would do is make writing synthetic functions "by hand" to implement comprehensions more uniform, because "parentlocal" would handle the corner cases by itself instead of making the programmer figure out when and where they need to type "nonlocal", "global", and/or cruft to establish a name as local to a block in which the name otherwise does't appear as a binding target.<br><br>But to the extent that doing such translations by hand is meant to be "educational", it's more educational to learn how to do that stuff yourself.</div></div></div>