On Sat, Oct 30, 2021 at 09:31:38PM -0400, David Mertz, Ph.D. wrote:
> Both the choice of syntax and the discussion of proposed implementation
> (both yours and Steven's) would make it more difficult later to advocate
> and implement a more general "deferred" mechanism in the future.
The choice of syntax would be independent of a more general deferred
mechanism. Even if we had such a mechanism (and we do... see below) we
would still want a short, readable way to mark parameters to the
interpreter to use them.
We already have various such forms (generator comprehensions, Futures?,
Promises?), including functions themselves. We can defer evaluating an
expression by putting it in a function:
x + 1 # eagerly evaluated right now
obj = lambda: x + 1 # defer evaluation
...
obj() # and evaluate
or a string (evaluate it later with eval() or exec()). So, right now, we
could implement delayed evaluation of defaults:
# I want a new list each time.
func(arg=lambda: []):
arg = arg()
This is inconvenient and annoying. The signature is obfuscated. The
calling convention becomes:
result = func(lambda: [1, 2, 3])
instead of the more natural `func([1, 2, 3])`. What this proposal brings
is a way of keeping the most natural signature, the most natural calling
convention, and still automatically delaying the evaluation.
All we need is one tiny bit of new syntax:
def func(@arg=expression) # this is the best :-)
plus some backend stuff in the interpreter, a few dunders in function
objects. Maybe a new inspect function.
A more general mechanism for deferring the execution of code is
interesting but also a much bigger problem to solve. We already have at
least one way to do it, provided the user is willing to explicitly call
the function object, or eval() the string. Unless the deferred object
gives us some wildly powerful new functionality, such as automagic
evaluation on need (and that is a hard problem), it isn't clear why we
would bother.
> I'm not sure what I think of a general statement like:
>
> @do_later = fun1(data) + fun2(data)
do_later = lambda: fun1(data) + fun2(data)
# much later
result = do_later()
--
Steve
_______________________________________________
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/2PRICIAFVZBF3MV2RG3F5EOR4NCXVWEL/
Code of Conduct: http://python.org/psf/codeofconduct/
