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

[Ethan Furman]

On 03/01/2018 09:08 PM, Nick Coghlan wrote:
> On 1 March 2018 at 19:30, Paul Moore <p.f.moore at gmail.com wrote:
>> On 1 March 2018 at 06:40, Chris Angelico wrote:
>>> On Thu, Mar 1, 2018 at 3:31 PM, Nick Coghlan wrote:

>>>> Since ".NAME" is illegal for both variable and attribute names, this makes
>>>> the fact statement locals are a distinct namespace visible to readers as
>>>> well as to the compiler, and also reduces the syntactic ambiguity in with
>>>> statements and exception handlers.
>>>
>>> I've mentioned this in the alternate syntaxes, but I don't like having
>>> to state a variable's scope in its name. Python doesn't force us to
>>> adorn all global names with a character, and the difference between
>>> function-local and statement-local is generally less important than
>>> the difference between global and function-local. But it IS a viable
>>> syntax, and I'm saying so in the PEP.
>>
>> Agreed. This feels far to much like Perl's "sigils" that attach to a
>> name ($var is a scalar, @var is a list, etc). Strong -1 from me.
>
>
> While that's a fair criticism, one of the current challenges with Python's variable naming is that given a NAME
> reference, there are already several potential places for that name to be resolved:
>
> * the current local scope
> * an enclosing function scope
> * the module globals
> * the builtin namespace
>
> This means the compiler has to be conservative and assume that if a name isn't visible as a local namespace entry or as
> a closure reference, then it will still be available at runtime (somehow). Structural linters and static analysers like
> pylint or mypy can do better and say "We can't figure out how you're expecting this name reference to be resolved at
> runtime", but it's still a very complex system to try to reason about when reading a code snippet.
>
> 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).

No grammatical grit on anyone's monitor, no confusion about which variable is being accessed, and no confusion about the 
lifetime of that variable (okay, no /extra/ confusion ;) .

Maybe somebody could explain why a statement-local limited scope variable is better than an ordinary well-understood 
local-scope variable?  Particularly why it's better enough to justify more line-noise in the syntax.  I'm willing to be 
convinced (not happy to, just willing ;) .

--
~Ethan~