[Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

Guido van Rossum guido at python.org
Sun Mar 25 01:34:59 EDT 2018


This is a super complex topic. There are at least three separate levels of
critique possible, and all are important.

First there is the clarity of the PEP. Steven D'Aprano has given you great
detailed feedback here and you should take it to heart (even if you
disagree with his opinion about the specifics). I'd also recommend treating
some of the "rejected alternatives" more like "open issues" (which are to
be resolved during the review and feedback cycle). And you probably need
some new terminology -- the abbreviation SNLB is awkward (I keep having to
look it up), and I think we need a short, crisp name for the new variable
type.

Then there is the issue of syntax. While `(f() as x)` is a cool idea (and
we should try to recover who deserves credit for first proposing it), it's
easy to overlook in the middle of an exception. It's arguably more
confusing because the scoping rules you propose are so different from the
existing three other uses of `as NAME` -- and it causes an ugly wart in the
PEP because two of those other uses are syntactically so close that you
propose to ban SNLBs there. When it comes to alternatives, I think we've
brainwashed ourselves into believing that inline assignments using `=` are
evil that it's hard to objectively explain why it's bad -- we're just
repeating the mantra here. I wish we could do more quantitative research
into how bad this actually is in languages that do have it. We should also
keep an open mind about alternative solutions present in other languages.
Here it would be nice if we had some qualitative research into what other
languages actually do (both about syntax and about semantics, for sure).

The third issue is that of semantics. I actually see two issues here. One
is whether we need a new scope (and whether it should be as weird as
proposed). Steven seems to think we don't. I'm not sure that the
counter-argument that we're already down that path with comprehension
scopes is strong enough. The other issue is that, if we decide we *do* need
(or want) statement-local scopes, the PEP must specify the exact scope of a
name bound at any point in a statement. E.g. is `d[x] = (f() as x)` valid?
And what should we do if a name may or may not be bound, as in `if (f(1) as
x) or (f(2) as y): g(y)` -- should that be a compile-time error (since we
can easily tell that y isn't always defined when `g(y)` is called) or a
runtime error (as we do for unbound "classic" locals)? And there are
further details, e.g. are these really not allowed to be closures? And are
they single-assignment? (Or can you do e.g. `(f(1) as x) + (f(2) as x)`?)

I'm not sure if there are still places in Python where evaluation order is
unspecified, but I suspect there are (at the very least the reference
manual is incomplete in specifying the exact rules, e.g. I can't find words
specifying the evaluation order in a slice). We'll need to fix all of
those, otherwise the use of local name bindings in such cases would have
unspecified semantics (or the evaluation order could suddenly shift when a
local name binding was added).

So, there are lots of interesting questions! I do think there are somewhat
compelling use cases; more than comprehensions (which I think are already
over-used) I find myself frequently wishing for a better way to write

m = pat.match(text)
if m:
    g = m.group(0)
    if check(g):  # Some check that's not easily expressed as a regex
        print(g)

It would be nice if I could write that as

if (m = pat.match(text)) and check((g = m.group(0))):
    print(g)

or

if (pat.match(text) as m) and check((m.group(0) as g)):
    print(g)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180324/187c7220/attachment-0001.html>


More information about the Python-ideas mailing list