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

[Nick Coghlan]

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 <rosuav at gmail.com> wrote:
> > On Thu, Mar 1, 2018 at 3:31 PM, Nick Coghlan <ncoghlan at gmail.com> 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).

Thus the intent behind the ".NAME" suggestion is to ask whether or not it's
possible to allow for name bindings that are strictly local to a
compilation unit (i.e. without allowing dynamic runtime access to outer
scopes or from contained scopes), *without* incurring the cost of making
ordinary NAME references even more complicated to understand.

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/20180302/4bffe995/attachment-0001.html>