Discussing PEP 572

As is often the case, the python-ideas mailing list hosted a discussion about a Python Enhancement Proposal (PEP) recently. In some sense, this particular PEP was created to try to gather together the pros and cons of a feature idea that regularly crops up: statement-local bindings for variable names. But the discussion of the PEP went in enough different directions that it led to calls for an entirely different type of medium in which to have those kinds of discussions.

PEP 572 ("Syntax for Statement-Local Name Bindings") has been through two revisions at this point, with robust discussion of both on python-ideas. The idea is that values with short lifetimes (for the duration of a single statement) may need to be referred to more than once during that lifetime. The canonical example from the PEP is:

    stuff = [ [f(x), f(x)] for x in range(5) ]

That works just fine, but if f() is costly or has side effects, that price will be paid twice in creating the list of lists. PEP 572 proposes new syntax that would allow any Python expression expr to be replaced with (expr as name); it would have the same value as the expression but also bind that value to name. That binding would only last until the end of the statement that contained it. Using that would allow the above example to be written as follows:

    stuff = [ [(f(x) as y), y] for x in range(5) ]

The comments on the first posting went in a bunch of different directions, some of which were anticipated by PEP author Chris Angelico as "open questions" in the PEP. Mostly those questions concerned corner cases of various sorts, such as how to handle the statement-local name bindings (SLNBs) for names that have already been used:

    (x, (1 as x), x)

Should the SLNB x shadow the x in the wider scope? Furthermore, there were questions (and a variety of answers) on what the following code should do:

    b = (3 as b)

The existing prototype implementation creates the SLNB for b before doing the lookup for the assignment; thus it assigns to the statement-local b, which goes out of scope at the end of the statement. So it effectively does nothing—which could easily be confusing.

The list comprehension example given in the PEP is not the truly interesting use case, at least for some participating in the thread. The SLNB is active until the end of the statement, which includes blocks, so the following would also be possible:

    if (re.search(pat, text) as match):
	print("Found:", match.group(0))

    while (sock.read() as data):
	print("Received data:", data)

For those, match and data would go out of scope after the completion of their blocks.

As is fairly normal for discussion on a mailing list, the thread had several lengthy sub-threads with comments (and replies several levels deep) that touched on multiple pieces of the PEP. That did not sit well with Robert Vanden Eynde, who asked: "Isn't it easier to talk on a forum?" As might be guessed, the answer from several was "no", but there was more to it than that. Vanden Eynde said:

Several participants expanded on their opposition to a forum-style discussion; many have built up a great deal of tooling to handle email, much of which is not usable in a web-based forum. Stephen J. Turnbull, who is one of the developers of the Mailman mailing-list manager—used by python-ideas and others—had a lengthy reply that acknowledged the longtime tension between forums and mailing lists. Like the subject of the PEP, discussion media has been batted around in the Python community for quite some time. According to Turnbull, it boils down to this:

Oleg Broytman also offered up his analysis of web forums versus mailing lists in the thread; it reiterates some of what Turnbull said while adding some other points. Forums may have a lower barrier to entry, but it simply isn't possible for everyone to apply their own customizations to any particular forum installation—not to mention trying to get a single, cohesive "look and feel" across the many different forum implementations available. Email may lack for some things, but it is a simple format that has a myriad of ways to access it—including from the web.

But there is a hybrid solution available: Mailman 3 (MM3). Currently python-ideas is managed by Mailman 2, but some smaller Python mailing lists have made the switch and python-ideas will likely follow soon. Switching to MM3 brings the HyperKitty archiver along with it. HyperKitty provides a web-forum-style archiver, where users can browse, post, and reply to mailing list messages. As Guido van Rossum said: "I think this is the best of both worlds."

Nick Coghlan suggested that python-ideas be used as a guinea pig for migrating some of the larger mailing lists (including, eventually, python-dev) to MM3. Few seemed opposed to the idea, though it will bifurcate the archives; after the switch, all of the newly archived messages will have a different URL. Someone could perhaps convert the old archives to the new (while preserving the existing links) at some point.

This is a discussion that goes on in various parts of our communities with some frequency. We looked at a similar discussion regarding python-ideas back in February 2016. We will certainly see it again. Email is increasingly falling out of favor as a communications mechanism, so the push for alternatives is only likely to grow stronger over time. It is not that hard to imagine that new developers in five or ten years (or ...) will not have even heard of email except as something the old-timers talk about—like gopher or rotary telephones.

Meanwhile, back at the PEP. Angelico posted a second version based on the feedback he had received. It provided more examples, a list of syntax alternatives, as well as discussion of the consequences of Python execution order. Several people in both threads thanked Angelico for creating the PEP as a place to hold the various pieces of the discussion of this feature. The clear implication is that many think PEP 572 will be rejected, but that it is valuable nevertheless. Angelico will not be surprised if that happens:

Most of those commenting on the revision are either against the idea of SLNBs entirely or would like to see a different syntax used to specify them. There is no major agreement on which of the half-dozen alternatives is best, though, so it is a little hard to see Van Rossum (who has been conspicuously silent on the feature) jumping in to resolve the syntax question in some kind of positive ruling on the PEP. A much more likely outcome is that PEP 572 gets rejected, but that python-ideas moves in a direction that makes it more friendly for those who prefer forums for discussion. The next time the SLNB feature rears it head in email or on the web, though, folks can point to PEP 572 and not have to rehash it all again.

---

to post comments

(setq stuff
      (map (lambda (x) (let v (f x) (list v v)))
           (range 5)))

  stuff = [ (lambda y: [y, y])(f(x)) for x in range(5) ]

  stuff = [ [(f(x) as y), y] for x in range(5) ]

  stuff = [ f(x) as y in [y, y] for x in range(5) ]

  #while (sock.read() as data in data):
  while (sock.read() as data):
      print("Received data:", data)