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

[Guido van Rossum]

On Mon, Mar 26, 2018 at 7:57 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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.
>

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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180326/8ccd8c87/attachment.html>