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

Nick Coghlan ncoghlan at gmail.com
Fri Mar 2 06:15:35 EST 2018


On 2 March 2018 at 19:05, Paul Moore <p.f.moore at gmail.com> wrote:

> 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.
>

Those examples didn't trigger the suggestion: the suggestion was borne from
the fact that I don't think it should be possible to close over statement
locals.

If you can't close over statement locals, then it isn't acceptable to allow
this scenario:

    x = 12
    if (True as x):
        def f():
            return x
        print(x, f()) # "True True"? Or "True 12"?
    print(x, f()) # "12 12", but it's not obvious why it isn't "True True"

By contrast, if the two kinds of local namespace are visibly different,
then the nested scope *can't* give the appearance of referencing the
statement local:

    x = 12
    if (True as .x):
        def f():
            return x
        print(.x, x, f()) # Clearly "True, 12, 12", since x never gets
rebound
    print(x, f()) # Clearly "12, 12", since x never gets rebound


>
> [...]
>
> > 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.
>

PEP 3150 ended up needing syntactic markers as well, to handle the forward
references to names set in the `given` clause while staying within the
LL(1) parsing design constraint imposed on Python's grammar.

Currently it proposes `?.name` as that marker, with `?` referring to the
entire given namespace, but it could equally well use `.name` instead (and
if you wanted a reference to a namespace instead, you'd need to define one
inside the given clause).

One of the key *problems* with PEP 3150 though is that it doesn't compose
nicely with other compound statements, whereas PEP 572 does (by treating
each statement as its own extent - PEP 3150 then just provides a way to add
a suite to statements that don't already have one of their own).


> > 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.
>

Right, but that extra notation *does* convey useful information to a reader
that better enables local reasoning about a piece of code. Currently, if
you're looking at an unfamiliar function and see a name you don't
recognise, then you need to search the whole module for that name to see
whether or not it's defined anywhere. Even if it's missing, you may still
need to check for dynamic injection of module level names via globals().

Seeing ".name" would be different (both for the compiler and for the human
reader): if such a reference can't be resolved explicitly within the scope
of the current statement, then *it's a bug* (and the compiler would be able
to flag it as such at compile time).

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/e0102c72/attachment.html>


More information about the Python-ideas mailing list