On Fri, 24 Jun 2022 at 17:51, Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:
Then the question is, why do we need syntax? Well, there's the PEP 671 rationales for deferring function argument defaults.
Which the OP hasn't actually explained in a way that works yet. A vanilla argument default value, with any sort of deferred object as described by anyone in this thread so far, would not achieve the semantics of a late-bound argument default - usually failing on this test: def f(x=[]): x.append(1) return x How do you make this construct a new list every time it is called with no arguments? "def f(x=later [])" just delays the construction of the single default list until the first time it's needed, but it won't create a new one.
There is also the question of whether name binding should trigger evalution. If so,
a = defer b
would (somewhat similar to iter) defer normal b (this could be optimized by checking for non-mutables) and "re-defer" a deferred b (ie, just bind it to a without evaluation).
Not sure what you mean by "similar to iter", but my understanding of "a = defer b" (or "a = later b" or whatever the syntax is) is "when a gets referenced, go figure out what b is", and that's going to have to go and poke b once a gets poked. There could be an optimization here, but the vanilla interpretation is that it's a new thunk. The underlying b won't be evaluated at this point.
The same consideration would apply to "as" and function arguments (possibly with different resolutions! I'm probably missing some name-binding syntax here, but it should be clear where this going).
It's not really the name binding that's the consideration - it's the lookup. Borrowing CPython's bytecode to explain, "a = b" looks like this: "Load b, then store your latest thing into a". (Both the load and the store need to know what kind of name to work with - a fast local, a closure cell (whether from the outer or inner function), a global, or something harder to optimize ("LOAD_NAME" and "STORE_NAME" are used in class context).) Name binding should never trigger evaluation, as that would make it impossible to use deferred objects at all; but using the name on the RHS would constitute a load, and based on some versions of the proposal, that is the point at which evaluation happens. ChrisA