On 26/03/2018 16:57, Guido van Rossum wrote:
On Mon, Mar 26, 2018 at 7:57 AM, Nick Coghlan
mailto:ncoghlan@gmail.com> wrote: On 26 March 2018 at 14:34, Guido van Rossum
mailto:guido@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