
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