[Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

Nick Coghlan ncoghlan at gmail.com
Mon Mar 26 10:57:28 EDT 2018


On 26 March 2018 at 14:34, Guido van Rossum <guido at 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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list