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

[Rob Cliffe]

On 26/03/2018 16:57, Guido van Rossum wrote:
> On Mon, Mar 26, 2018 at 7:57 AM, Nick Coghlan <ncoghlan at gmail.com 
> <mailto:ncoghlan at gmail.com>> wrote:
>
>     On 26 March 2018 at 14:34, Guido van Rossum <guido at python.org
>     <mailto: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).
True.  But there is a case for also saying that the for-loop variable's 
scope should have been limited to the for-loop-suite. (Not that it's 
feasible to make that change now, of course.)

If I had a time-machine, I would add an assignment character (probably 
looking something like <- ) to the original ASCII character set.  Then 
"=" means equality - job done.
Actually, probably a right-assignment character ( -> ) as well.

Rob Cliffe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180326/b97787b7/attachment.html>