On 2 March 2018 at 05:08, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 1 March 2018 at 19:30, Paul Moore <p.f.mo...@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.

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to