On 2 March 2018 at 05:08, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 1 March 2018 at 19:30, Paul Moore <p.f.moore@gmail.com> wrote:
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
While that is true, the current scenario is (conceptually, at least) a relatively traditional set of 4 nested namespaces, with name resolution working from innermost to outermost, and with the extent of the scopes being pretty clearly defined. So although the *compiler* may have to defer a chunk of that resolution to runtime, the human reader can work with a relatively conventional model and not hit problems in the majority of cases. The problem with statement local variables is that the extent over which the name is in scope is not as clear to the human reader (the rules the *compiler* follows may be precise, but they aren't obvious to the human reader - that's the root of the debate I'm having with Chris over "what the reference implementation does isn't a sufficient spec"). In particular, assignment statements are non-obvious, as shown by the examples that triggered your suggestion of a "." prefix. [...]
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).
Well, an alternative to a syntactic marker would be an easy-to-determine extent. That's where proposals like PEP 3150 (the "given" clause) work better, because they provide a clearer indication of the extent of the new scope. IMO, lack of a well-defined extent is a flaw of this proposal, and syntactic markers are essentially a (ugly) workaround for that flaw.
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.
... or the cost of imposing a more user-visible indication of the extent of the scope into the proposal. Paul