PEP 308: A PEP Writer's Experience - PRO

Andrew Henshaw andrew.henshaw at gtri.gatech.edu
Mon Feb 10 01:37:47 EST 2003


Erik Max Francis wrote:

> Andrew Henshaw wrote:
> 
>> If it were possible, then we might have (arbitrarily choosing a
>> qualifier)
>> 
>> def iff(cond, %expr1, %expr2):
>>     if cond:
>>         return expr1
>>     else:
>>         return expr2
>> 
>> Plus that whole lazy-evaluation-infinite-data-structures capability
>> comes
>> along as well (assuming someone very clever can develop it).
> 
> But you really already have this, with lambdas, just not as an implicit
> syntax.  I'm not sure what the implicit syntax gets you, really, except
> turning every conceivable line of code you run across into a minefield
> -- is this argument going to be lazily evaluated (maybe never)?  Is this
> one?  I have to keep checking back to the function definition and
> looking for a % [or whatever might be chosen] to find out.  That sounds
> kind of scary.

I share your concern about the "scariness", which is why I questioned 
whether it would be dangerous, in my original post.  I wonder if someone 
could provide an authoritative comment on this aspect.

On the other hand, I'm not particularly opposed to knowing the arguments 
(and qualifiers) for any particular function that I'm about to use.

> 
>> I'm certainly opposed to adding line-noise artifacts to Python, but
>> this
>> would be very rarely used, it would be restricted to the def
>> statement, and
>> it would be documented along with the * and ** qualifiers.
> 
> I'm not sure this formulation really stands out as a big winner, when
> you can already use zero-argument lambdas as thunks (provided you call
> them when you want them) in the "very rare" (your words) case where you
> need this.
> 

Actually, I meant that the use of the qualifier (line noise) would be very 
rare - it would only be used in the definition of a function that specified 
lazy evaluation.  That is not to say that the use of such a function would 
be very rare.  In fact, I would expect that the opposite would be the case, 
which is part of the rationale behind placing the qualifier into the 
function definition.

Perhaps, I am looking at this backwards, however.  In this case (iff 
function), it's clear that the function definition needs to support lazy 
evaluation.  But, I can see where there would be cases where it didn't look 
like it was needed; but, the caller is annoyed that he can't use my 
function "lazily".

Despite that, I don't believe that lambda would be a good explicit solution, 
either.

Regards,

Andy





More information about the Python-list mailing list