PEP 308: A PEP Writer's Experience - PRO

Andrew Henshaw andrew.henshaw at
Mon Feb 10 05:31:38 CET 2003

Andrew Koenig wrote:

> Samuele> As you might know the "cutest" (my take) general solution to
> Samuele> the problem in current Python (performance aside), has been
> Samuele> posted by Gerald S. Williams to python-dev:
> Samuele> ife = lambda box: box[0]
> Samuele> z = ife(cond and [x] or [y])
> Samuele> if Python had had a ternary cond op, I would never have seen
> Samuele> that <sniff>.
> You're right -- that's about the nicest workaround I've seen.
> But I think I can improve it a tiny bit:
>         ife = list.pop
> Shorter and faster, yes?

That's nice.  

This is getting closer to the discussion that I'd like to see - that is, 
making this "ternary operator" into a function.

I understand about the lazy evaluation problem, and I wonder if that 
couldn't be solved in general, and we'd get a bonus out of this whole 
discussion.  In other words, if someone could propose a workable lazy 
evaluation solution, then we'd have the benefits of that technology, plus 
we'd could have a cleaner (in my opinion) solution to the problem at hand.

Why cleaner?  Personally, I find the use of multiple keywords and intermixed 
expressions on a single line, with no punctuation, difficult to parse 
(particularly, when chained).  To me

        expr1 keyword1 cond keyword2 expr2

is more difficult to read than
        function(cond, expr1, expr2)

The commas also provide the benefit of naturally supporting multiples lines, 
such as:

In addition, the required parentheses make abuse of the construct less 
probable.  For example,

        expr1 keyword1 cond1 keyword2 expr2 keyword1 cond2 keyword2 expr3 (I think)

        function(cond1, expr1, function(cond2, expr2, expr3))

seems to be a win for the function style.  Perhaps, I'm making things worse 
by abstracting the terms, too much.

        expr1 if cond1 else expr2 if cond2 else expr3

        iff(cond1, expr1, iff(cond2, expr2, expr3))

Back to the top of this post - a workaround has been suggested that 
essentially achieves lazy evaluation.  Clearly one of the problems here is 
that the caller has to coerce that capability, instead of the called 
function providing it.

Would it not be reasonably possible (even Pythonic), for there to be an 
argument qualifier that denoted lazy evaluation in the function definition, 
similar to the * and ** qualifiers now used?  Or is lazy evaluation itself 
too difficult (or dangerous) to implement in Python?
If it were possible, then we might have (arbitrarily choosing a qualifier)

def iff(cond, %expr1, %expr2):
    if cond:
        return expr1
        return expr2

Plus that whole lazy-evaluation-infinite-data-structures capability comes 
along as well (assuming someone very clever can develop it).

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.



More information about the Python-list mailing list