On 1 March 2018 at 19:30, Paul Moore firstname.lastname@example.org wrote:
On 1 March 2018 at 06:40, Chris Angelico email@example.com wrote:
On Thu, Mar 1, 2018 at 3:31 PM, Nick Coghlan firstname.lastname@example.org wrote:
Since ".NAME" is illegal for both variable and attribute names, this
the fact statement locals are a distinct namespace visible to readers as well as to the compiler, and also reduces the syntactic ambiguity in
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.