On Thu, 2008-09-18 at 16:10 -0400, Terry Reedy wrote: > Cliff Wells wrote: > > Whenever Python encounters a declaration of > > a function with a lazy argument it creates the latter. This would allow > > Python to know at runtime how to handle it. > > This was already assumed in my original 'select between them at runtime > according to an attribute of the function'. Sorry, I must have missed that in reading your reply, but yes both would work. Which of them would be preferable is an implementation detail outside my scope of knowledge. > > The difference could be > > transparent to user code (although it might be unappealing to disguise > > such a difference). > > Unless the argument expression has visible side-effects when evaluated. I think this is the stickiest point (from a philosophical perspective anyway). It's true an explicit side-effect might not happen. However, we already have the inverse of this problem (simple expressions disguising side-effects). Consider: a + b Given that a and be might not be numeric types, what does the above mean? Someone mentioned earlier (sorry, lost the reference) that they found the idea of having to refer to a function signature to unappealing, but magic methods already present a similar problem (disguising potential side-effects). We depend on sane library authors to not abuse this feature. In any case, whenever encountering such a construct we are forced to either assume that the class author did the right thing and the operation makes sense or we refer to the documentation/source to decipher the meaning. I think what I'm suggesting isn't so dissimilar. I will admit that the mere *presence* of a class implies that such side-effects might be present whereas functions only appear ordinary, so there is a tiny bit of fair warning. Still, when encountering something like iff ( cond, iftrue, iffalse ) in a library, I think what I'm suggesting is the least surprising result. It comes down to library and function authors making the intention plain rather than the language providing a specific construct for doing so. I find this acceptable, but others may not. > I think there are also namespace issues that you have missed. Consider > > def f(`a,`b): # ` indicates lazy evaulation, after Lisp's 'quote > ..... > blaf + f(a+b,c) -3 > When f evaluates a bound to 'a+b', it has to *not* resolve 'b' to f's > 'b' but to the caller's 'b'. As someone else said, the unevaluated code > for 'a+b' is not enough. A full enclosing function is needed. Yes, I realize this. I think the overhead of creating a closure would be acceptable provided it only affected this explicitly specified case and not function calls in general. I've long ago accepted that expressive power and efficiency are often mutually exclusive (which I why I moved from C to Python many years ago). Cliff