On 03/01/2018 09:08 PM, Nick Coghlan wrote:
On 1 March 2018 at 19:30, Paul Moore <p.f.mo...@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~
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
