On Mon, Mar 26, 2018 at 7:57 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 26 March 2018 at 14:34, Guido van Rossum <gu...@python.org> wrote: > > Not so fast. There's a perfectly reasonable alternative to sublocal > scopes > > -- just let it assign to a local variable in the containing scope. That's > > the same as what Python does for for-loop variables. Note that for > > comprehensions it still happens to do the right thing (assuming we > interpret > > the comprehension's private local scope to be the containing scope). > > I finally remembered one of the original reasons that allowing > embedded assignment to target regular locals bothered me: it makes > named subexpressions public members of the API if you use them at > class or module scope. (I sent an off-list email to Chris about that > yesterday, so the next update to the PEP is going to take it into > account). > > Similarly, if you use a named subexpression in a generator or > coroutine and it gets placed in the regular locals() namespace, then > you've now made that reference live for as long as the generator or > coroutine does, even if you never need it again. > > By contrast, the sublocals idea strives to keep the *lifecycle* impact > of naming a subexpression as negligible as possible - while a named > subexpression might live a little longer than it used to as an > anonymous subexpression (or substantially longer in the case of > compound statement headers), it still wouldn't survive past the end of > the statement where it appeared. > But this is not new: if you use a for-loop to initialize some class-level structure you have the same problem. There is also a standard solution (just 'del' it). -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/