<div dir="ltr"><div class="gmail_quote"><div>[Steve Dower]<br>> Okay, so as far as the specification goes, saying "assignment <br></div><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> expressions in comprehensions get or create a cell variable in the <br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> defining scope and update its value" satisfies me just fine (or some <br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> other wording that more closely mirrors the actual behaviour - all my <br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> work here is on my own compiler, not the actual CPython one, and I don't <br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> know that they're identical).<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote>><br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> I don't think this should be left assumed by the PEP. If it's likely to <br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> be a restriction on other implementations to say "cell variable", then <br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> say "For example, in CPython, ..."</div><div class="gmail_quote"><br>The problem:  nothing about Python's scoping is changed by this PEP, so saying anything related to the implementation of scoping risks giving a misleading impression that something about scoping _is_ being changed.<br><br>The PEP certainly needs to define the intended scope of assignment-expression targets in all cases.  It already tried, with perhaps too few words.  But it strikes me as counterproductive to go on to say anything about how scopes are implemented.  If, e.g., the PEP is clear that in<br><br>    def f():</div><div class="gmail_quote">        return (a := i for i in range(5))<br><br>`a` is local to `f` and `i` is local to a directly nested scope, what's left to the imagination?  Well, the implementations of scopes and closures.  None of which the PEP changes.  The semantics of `i` haven't changed from what we already have, neither the visibility nor extent of the generator expression object returned.<br><br>The only new thing is specifying the scope of `a`, where "local to f" means exactly the same thing as for any other name local to a function today.  So far as the PEP semantics go, it doesn't even matter whether an implementation _does_ implement some form of closure as such.  It just has to provide the visible semantics of <u>lexically</u> nested scopes with indefinite extent, by whatever means it likes best.  That's what "local to f" means (and has meant all along - well, since lexically nested scopes were first introduced).<br><br>Would it help to say "and by 'local to f' we mean the same thing we meant before this PEP was written"?  Probably not ;-)  If someone doesn't know what "name N belongs to scope S" means, that needs to get a clear answer, but it's a fundamental question that's quite independent of this particular PEP.<br><br>That said, I bet it would be helpful to give some examples that show how CPython intends to implement this stuff, via giving explicit nested workalike Python functions decorated with scope declarations.  The concreteness of that is helpful.  The eternal problem with that is finding a way to stop readers from taking the "workalike functions" too literally (e.g., "but i tried it and it doesn't generate exactly the same byte code!").</div><div class="gmail_quote"><br></div></div>