(a==b) ? 'Yes' : 'No'

Steve Holden steve at holdenweb.com
Fri Apr 2 22:35:58 CEST 2010

kj wrote:
> In <mailman.1326.1269971785.23598.python-list at python.org> Steve Holden <steve at holdenweb.com> writes:
>> John Nagle wrote:
>>> Chris Rebert wrote:
>>>> On Tue, Mar 30, 2010 at 8:40 AM, gentlestone <tibor.beck at hotmail.com>
>>>> wrote:
>>>>> Hi, how can I write the popular C/JAVA syntax in Python?
>>>>> Java example:
>>>>>    return (a==b) ? 'Yes' : 'No'
>>>>> My first idea is:
>>>>>    return ('No','Yes')[bool(a==b)]
>>>>> Is there a more elegant/common python expression for this?
>>>> Yes, Python has ternary operator-like syntax:
>>>> return ('Yes' if a==b else 'No')
>>>> Note that this requires a recent version of Python.
>>>     Who let the dogs in?  That's awful syntax.
>> Yes, that's deliberately awful syntax. Guido designed it that way to
>> ensure that people didn't aver-use it, thereby reducing the readability
>> of Python applications.
> Is that for real???  It's the QWERTY rationale all over again.  Swell.
I may be misrepresenting Guido here. Unlike Tim Peters I have never
claimed to be able to channel him.

> "Let's preserve readability by making the syntax so ugly that people
> won't use it."???  That's just perverse.  (It would have been more
> reassuring if the reason had been simply that Guido has an inexplicable
> dislike of ternary expressions just like one may have an inexplicable
> dislike of Broadway musicals.)
I don't think his dislike of them is inexplicable. They do, when
over-used, lead to the most impenetrable code, which as a bonus is
frequently buggy.

> First, I don't understand why ternary expressions are inherently
> hard to read, and therefore must be discouraged in the name of
> overall code readability.  Sure, one can write impenetrable ternary
> expressions, but one can write impenetrable binary expressions or
> impenetrable anything else, even in Python.  That the expression
> is ternary has nothing to do with it.
I think it does - the scope of the expressions is inherently longer when
three terms are involved rather than just tow.

> Second, sticking the test between the two alternatives goes against
> a vast tradition in programming languages.  This tradition inevitably
> fosters habits and expectations when reading code, so going against
> it automatically makes code less readable to all who were educated
> in that tradition.  Consider, for example, the readability of the
> following if statement in some hypothetical language:
> begin:
>    # this branch will be executed if test() (see below) evaluates
>    # to true
>    x = y + z   
>    a = b * x + c   
>    i = j - k 
>    p = log(q) 
> if test() else: 
>    x = -(y + z)
>    a = b * x + 2 * c
>    i = j + k
>    p = -log(q) 
> If you find this hard to read (I do), the quetion is "why?".  For
> me it's because, maybe through years of reading code, I've developed
> a habit that says: when you run into a fork in the logic, first
> understand what the decision hinges on.  Therefore, my brain will
> start hunting for that test, and it sucks to have to find it buried
> somewhere in the middle.  (Sure, one could justify this horrible
> syntax with an argument reminiscent of the one you gave for "A if
> X else B".  It goes like this: long blocks of code should be avoided
> in the name of readability; this syntax discourages long blocks of
> code because one doesn't want to skip too far ahead to find that
> test.  Ergo the end result is improved readability.  That's just
> nuts.)
It's precisely to avoid that kind of lunacy that the chosen form was
adopted. Conditional expressions aren't *meant* to be complex enough to
leave any doubt about their meaning. If you require such complexity
that's perfectly OK - just use an "if" statement.

> Anyway, I don't know of any other language that puts the test
> between the alternatives.  No doubt there's one out there, with
> emphasis on "out there"...
I understand you don't like it. The message handing down the decision is at


and consideration of many applicable points in the standard library is at


Disagree with the decision as you might, you can't argue that it was
made with insufficient consideration of the possible alternatives or the
merits of the solution.

Steve Holden           +1 571 484 6266   +1 800 494 3119
See PyCon Talks from Atlanta 2010  http://pycon.blip.tv/
Holden Web LLC                 http://www.holdenweb.com/
UPCOMING EVENTS:        http://holdenweb.eventbrite.com/

More information about the Python-list mailing list