Defending the ternary operator

Andrew Koenig ark at
Sat Feb 8 19:30:35 CET 2003

>> As an experiment, I went back through a 2800-line C program that I
>> wrote about 20 years ago (!) to see how often I used ?: and in what
>> context.  I figure that reading my own 20-year-old code is probably a
>> lot like reading some else's code.

Laura> The fact that you would not abuse a ternary does nothing to put
Laura> my mind at rest.  I've wished for a world where all the C and
Laura> C++ programs I have encountered have been written by you, many
Laura> times, sometimes in those exact words, as well.

I'm flattered :-)

Laura> If you don't think that it will be used very often, do you
Laura> admit that it might be on the side of 'diminishing returns', a
Laura> feature request that doesn't 'pull enough weight' to be worth
Laura> doing?  Or do you think that any language feature that is of
Laura> use to somebody should automatically go into a language to 'add
Laura> desired functionality'?  I doubt very much that you believe
Laura> this, (though if you do, we have found the disagreement, for
Laura> certain).  How do you determine if a proposed language feature
Laura> 'pulls enough weight'?

One way is by considering the alternatives.

For example, suppose I want to write

    z = max(x, y)

without calling a function.  Yes, I know that's contrived, but examples
often are.  I would like to be able to write

    z = x if x > y else y

Today I can't.  What can I do?  I can write

    if x > y:
        z = x
        z = y

in which I must utter "z" twice and might get it wrong one of those times.
Or I can write

    z = (x, y)[x <= y]

which evaluates x and y twice, and in which I must remember to invert
the condition.  Or I can write

    z = { True: x, False: y }[x > y]

which still evaluates x and y twice, and is getting wordy.

Or -- and this is what really convinces me -- I can write

    z = x > y and x or y

which looks really cool, and is just plain wrong, because if x is
0 and y is negative, the result is 0 instead of y.

It's this last example that really horrifies me, because people see
it, think that "if a then b else c" should be written as
"a and b or c", and then get into trouble.

The fact that people are suggesting such circumlocutions says to me
that there is a use for the feature, and the fact that people are
suggesting incorrect circumlocutions makes my skin crawl.

Andrew Koenig, ark at,

More information about the Python-list mailing list