From late-bound arguments to deferred computation, part 1

Back in November, we looked at a Python proposal to have function arguments with defaults that get evaluated when the function is called, rather than when it is defined. The article suggested that the discussion surrounding the proposal was likely to continue on for a ways—which it did—but it had died down by the end of last year. That all changed in mid-June, when the already voluminous discussion of the feature picked up again; once again, some people thought that applying the idea only to function arguments was too restrictive. Instead, a more general mechanism to defer evaluation was touted as something that could work for late-bound arguments while being useful for other use cases as well.

Background

Python programmers can specify default values for function arguments, which get used if no value is passed for the argument when the function is called. But that default value is determined by evaluating the expression at definition time, so the following will not do what is likely intended:

    def fn(a, max=len(a)):
        ...

That might look like max will default to the length of the argument a, but in reality it will default to length of some other a in an enclosing scope when the definition is being executed. If the other a does not exist, the definition will raise a NameError.

Chris Angelico wanted to provide a mechanism to tell the interpreter to evaluate the default expression when the function was called, which would fix that particular problem. He proposed using "=>" to indicate a late-bound default, so the definition of max would change to max=>len(a) in the example above. To that end, he authored PEP 671 ("Syntax for late-bound function argument defaults") in October and posted it to the python-ideas mailing list, which set off the first round of discussion that was covered in our article.

On December 1, he announced an updated version of the PEP, which set off an even longer discussion thread. The level of opposition to the feature had grown in the interim, it would seem. For some, the feature did not truly provide enough "bang for the buck"; there are simply not enough real-world uses of it to offset the cost in terms of development and maintenance. Beyond that, adding a feature like this increases the cognitive load of the language, which affects existing developers as well as those just learning Python.

But there was also a possible alternative that kept cropping up in the various discussions: deferred computation. Having a way to specify that an expression should not be evaluated until its value is truly needed would provide a more general solution—or so it is argued. But no PEP, or even concrete description, for deferred computation emerged, so proponents of PEP 671 were often frustrated by the amorphous nature of the supposed alternative. Things got rather heated in the discussion, to the point that a list moderator placed python-ideas in moderated mode for a day, but it all wound down without any sort of resolution in mid-December.

More discussion

That all changed in mid-June when the thread was revived by two posts, one from "Bluenix" opposed to the PEP and another by Steve Jorgensen strongly in favor of it. Angelico suggested that Bluenix create their own PEP "instead of just hating on my proposal"; he noted that it is more work to do so, of course, "but it would also be a lot more useful".

In response to Jorgensen, Rob Cliffe asked about the status of the PEP. Angelico said that he had wearied of the earlier discussion, so he had back-burnered the PEP; he had suggestions for how to potentially revive it, though it would seem that folks decided on more python-ideas discussion instead. That discussion got heated and contentious at times, as well; it seems clear that all "sides" have dug into their positions and there is little—or no—room for changing minds.

Another use case where Angelico sees value for late-bound defaults is with a default collection such as a list. The "obvious" way to write that probably does not do, what the programmer expects:

    # naive version
    def fn(arg=[]):    # creates the list at compile time
        ...

    # better version, but more verbose
    def fn(arg=None):
        if arg is None:
            arg = []   # creates the list each time
        ...

    # PEP 671 version
    def fn(arg=>[]):
        ...

The "naive" version will reuse the same list every time fn() is called without passing arg; the other two would create a new empty list every time. The extra code needed in the second version could be eliminated with PEP 671, but "I don't find that burdensome enough to want syntax", Stephen J. Turnbull said. Paul Moore agreed:

It's somewhat attractive in theory, adding a short form for something which people do tend to write out "longhand" at the moment. But the saving is relatively small, and there are a number of vaguely annoying edge cases that probably don't come up often, but overall just push the proposal into the "annoyingly complicated" area. The net result is that we get something that *might* help with a minor annoyance, but the cost in (theoretical, but necessary) complexity is just a bit too high.

One of those complexities is how to handle default values that refer to other arguments. The PEP specifies that late-bound defaults are evaluated in left-to-right order as specified in the function definition, but even then there are oddities, such as:

    def fn(n=>len(items), items=[]):
        ...

If items were a late-bound default, a call to fn() with no arguments would be illegal, because of the left-to-right rule. The PEP waffles a bit on what should happen with a (confusing) function definition like that; "implementations MAY choose to do so in two separate passes, first for all passed arguments and early-bound defaults, and then a second pass for late-bound defaults". As Moore noted, though, those and other edge cases should be rare.

Deferred computation

As before, David Mertz and Steven D'Aprano were the main proponents of at least considering a generalized deferred-computation mechanism before setting the late-bound argument syntax in stone. Mertz said that he still opposed the PEP, but that he might be swayed if a "soft keyword" version was proposed. Soft keywords are new keywords that are added to the language in a way that does not preclude their existing uses as variable and function names. New language keywords are generally avoided because of their impact on existing code, but the switch to a PEG parser for CPython allows context-specific keywords; for example, the match and case keywords for the structural pattern matching feature are soft keywords.

Mertz suggested that a keyword version of late-bound defaults, using later, defer, or delay, for example, would make the function-argument handling less of a special case. That keyword could be used in other contexts if the more-general deferred-computation mechanism appears. But it is clear that some participants were losing their patience with the constant "deferred computation" refrain in the absence of any kind of concrete specification (or even description) of how that might look. Cliffe said that the late-bound defaults and deferred computation (or "lazy evaluation" as he called it) are orthogonal to each other. He thought that raising lazy evaluation in the context of PEP 671 was off topic—or even FUD.

D'Aprano disagreed with the idea that the two are unrelated, however; "Late-bound defaults is a very small subset of lazy evaluation." There is a subtle difference, however, that Angelico raised (and not for the first time): the scope of the default evaluation specified in the PEP is rather different from what a generalized lazy scheme would provide. The PEP specifies that the evaluation of the default expression is done in the function's run-time scope:

    def fn(stuff, max=>len(stuff)):
	stuff.append(1)
	print(max)

So a call to fn([]) would print 0 since that is the length of stuff in the function before any code in it is run. But if max were deferred, thus only evaluated when it was needed for the print() call, it would print 1. There is some further weirdness that was not directly mentioned there, however: in the deferred case, if the print() call is moved up a line to before the append, it would print 0 as well. So the default argument would change value depending on where it is referred to in the function.

To a certain extent, D'Aprano waved away that objection. Angelico responded to that, clearly frustrated, by demanding that D'Aprano actually go implement what he was describing; "You'll find it's a LOT more problematic than you claim." He also suggested that D'Aprano simply specify what a deferred evaluation object would look like for Python and how it could be used to implement late-bound defaults, but Angelico's rhetoric gets in the way of what he is trying to say, as Brendan Barnwell pointed out. Moore also suggested toning things down; he said that Angelico is forgetting that there are other participants who may just be trying to follow along:

Asking for more concrete examples of the proposed alternative is reasonable. Getting frustrated when they are not provided is understandable, but doesn't help. Calling the proposed alternative "vapourware" just doubles down on the uncompromising "implement it or I'll ignore you" stance. And replying with increasingly frustrated posts that end up at a point where people like me can't even work out how we'd go looking to see whether anyone *had* provided concrete examples of deferred evaluation just makes things worse. All of which could have been avoided by simply including an early argument posted here in the PEP, under rejected alternatives, with a link to the post and a statement that "this was proposed as an alternative, but there's not enough detail provided to confirm how it would replace the existing proposal".

Moore's message refers back to an earlier exchange, where D'Aprano pushed for deferred evaluation to be added as part of the "rejected ideas" section of the PEP, which Angelico resisted. But Angelico did give some reasons why he felt the two concepts were not fully compatible:

Generic "lazy evaluation" is sufficient to do *some* of what can be done with late-bound argument defaults, but it is not sufficient for everything [...]

[...] Generic lazy evaluation should be processed at some point where the parameter is used, but late-bound defaults are evaluated as the function begins. They are orthogonal.

At the time, Moore suggested including some of that explanation into the PEP. Had that happened, perhaps some (small part) of the unpleasantness in the thread could have been avoided. Angelico did add some text about deferred evaluation back into the PEP a few days later, though.

Part 2

On June 21, Mertz posted the first version of his proto-PEP for "Generalized deferred computation". It was meant to flesh out the idea of a mechanism to defer the evaluation of Python expressions and to incorporate late-bound defaults as well. Stay tuned for part 2, which looks at the proposal and the reactions to it.

Index entries for this article
Python	Arguments
Python	Deferred computation
Python	Python Enhancement Proposals (PEP)/PEP 671

---

to post comments

def foo(x=lambda: []):
    return x() + [1, 2, 3]

$ time python3 -c 'import sys; sys.exit(0)'
real    0m0,016s

def foo(x?, max?):
  x ?= []
  max ?= len(x)
  ...

    arg ?= default
    arg = arg if arg is not _Unassigned else default

def a():
  if b():
    x = c()
  ...
  if d():
    print(x)
  ...

def f(x?):
   ...

def f(...):
  if [the caller provided a value for x]:
    x = [that value]