On Fri, 24 Jun 2022 at 17:51, Stephen J. Turnbull
<stephenjturnb...@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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/YRXO25NQEOJ7WFAIGLYWHKFWDZKEQ7U3/
Code of Conduct: http://python.org/psf/codeofconduct/
