[Python-ideas] PEP 572: Statement-Local Name Bindings

[Nick Coghlan]

On 3 March 2018 at 03:51, Ethan Furman <ethan at stoneleaf.us> wrote:

> On 03/02/2018 02:47 AM, Nick Coghlan wrote:
>
>> On 2 March 2018 at 16:39, Ethan Furman wrote:
>>
>>> On 03/01/2018 09:08 PM, Nick Coghlan wrote:
>>>
>>
> Adding statement local variables into that mix *without* some form of
>>>> syntactic marker would mean taking an already
>>>> complicated system, and making it even harder to reason about correctly
>>>> (especially if statement locals interact
>>>> with nested scopes differently from the way other locals in the same
>>>> scope do).
>>>>
>>>
>>> Seems like it would far easier and (IMHO) more useful to scale the
>>> proposal back from a statement scope to simple
>>> expression assignment, and the variable is whatever scope it would have
>>> been if assigned to outside the expression
>>> (default being local, but non-local or global if already declared as
>>> such).
>>>
>>
>> Because that would put us back in the exact same problematic situation we
>> had when "[x*x for x in sequence]" leaked the
>> iteration variable (only worse): no function locals would be safe, since
>> arbitrary expressions could clobber them, not
>> just name binding operations (assignment, import statements, for loops,
>> with statements, exception handlers, class and
>> function definitions).
>>
>
> Ah, right.  Since the PEP primarily covers comprehensions, but then went
> on to discuss multi-line statements, I had forgotten the comprehension
> part.  The answer is easy:  assignment expressions in comprehensions stay
> inside comprehensions, just like other inner comprehension variables
> already do (function sub-scope, after all).  Thank you for pointing that
> out.
>

That wasn't the point I was try to make: my attempted point was that I see
allowing an expression like "print((f() as x), x^2, x^3)" to overwrite the
regular function local "x" as being just as unacceptable as "data = [x^2
for x in sequence]" overwriting it, and we already decided that the latter
was sufficiently undesirable that we were willing to break backwards
compatibility in order to change it.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180303/f02c72ee/attachment.html>