Defending the ternary operator

[cribeiro at mail.inet.com.br]

To all Pythonistas,

I'm writing this to sum up my feelings regarding PEP 308 and some of the
arguments presented (pro and against). It will probably raise one or two
flame-like answers but I'm getting used to it :-)

Why is a ternary operator needed? The main reason is that it allows the
programmer to clearly express his intentions. The alternative idioms that
are frequently presented in c.l.p just doesn't cut it; they're mostly
clever hacks that abuse some side effects of the way logical operators and
expressions work in Python.

The main example are abuses of the following definition: false=0, true=1.
Most alternative solutions proposed to avoid the inclusion of the ternary
operator abuse this fact, either through indexing or by a clever
composition of logical operators. While I agree that the convention is a
fact of life, and that it does have solid foundations on binary logic and
past implementations of several languages, it does not seem right to abuse
it like this; it requires the programmer to be aware of this identity,
which is not obvious for beginners.

Many people say, 'explicit is better than implicit'. Well, idioms such as
[a,b][cond] are implicitly using the identity mentioned above. The same
goes for the and/or hacks: clever stuff, but not immediatelly obvious
unless you execute it mentally.

That leaves us with two main options: (a) traditional if-then-else
statements setting temporary variables, or (b) creating a brand new
ternary operator (as proposed by Guido).

Traditional if-then-else statements have their own problems. They're
lenghty for simple stuff, and may obfuscate the program logic. It would be
much better to use if statements only for 'big' decisions, the ones that
define the program's logic; small stuff such as choosing between two
representations to format data can be efficiently written as an inline
expression, leaving the logical flow of the program cleaner.

Now, look at it this way: the ternary operator is just 'syntactic sugar'.
It will make code easier to read. Almost every ocurrence of the ? operator
in C programs occur in short expressions, things that are much better
written inline than spread out over 4 lines. It can be abused, but many
other constructs can be abused if nested arbitrarily, and this does not
makes such constructs bad by themselves.

I also urge everyone on the list to be careful when considering options.
The automatic (but unconscious) reaction for many people is to stand up
against change. An open stance is important now, to careful evaluate all
the arguments. Eventually, some people may give it a try and rewrite some
of their actual code, just to see would it end up looking like.

I myself felt victim of this trap after reading Guido's email. I thought
that the syntax proposed was strange; a little weird, confusing, because
of the evaluation order. But the more I read it, the better it reads.


Carlos Ribeiro
cribeiro at mail.inet.com.br