The title of this thread is lazy... statement but it seems to me that expressions are the natural unit. If I want to do lazy evaluation today, I would use something like f(a, b, lambda: g(a,b)) where of course the g(a,b) is only evaluated when f wants to evaluate it. Of course f is responsible for explicitly evaluating that lambda. I think a lambda-like syntax like this: f(a, b, lazy: g(a,b)) would be easy to understand. Note that this puts the responsibility on the caller's side to say that the expression is lazy. That is, we don't do def f(a, b, lazy: d): or lazy: def(a, b, d): although this is allowed: def f(a, b, d=lazy: g()) There are several reasons I put the responsibility on the caller's side: (1) The caller is in the best position to know if evaluating a lazy expression is expensive enough that it's worth making lazy, and if making an expression lazy changes the order of evaluation in a bad way. (2) When we see a function call, we don't know for sure which function will be called so we'd have to compile both the inline and the lazy evaluation for each parameter. I'm not sure what this makes for the import case. --- Bruce

On Wed, Oct 15, 2008 at 5:25 PM, Greg Ewing wrote:

Jim Jewett wrote:

...

Part of the problem with setdefault is that calculating the default can be expensive.

There's already a superior replacement for setdefault, i.e. use a defaultdict.

Only if the default can be calculated by the dict itself. If some information from the calling site is needed, there still isn't a good answer. That is a rare case, but does overlap with the cases where calculation actually is expensive. -jJ