[Python-ideas] And now for something completely different

[Cliff Wells]

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