On 26/03/2018 16:57, Guido van Rossum wrote:
On Mon, Mar 26, 2018 at 7:57 AM, Nick Coghlan <ncogh...@gmail.com
<mailto:ncogh...@gmail.com>> wrote:
On 26 March 2018 at 14:34, Guido van Rossum <gu...@python.org
<mailto: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).
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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
