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

[Steve Holden]

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

http://mail.python.org/pipermail/python-dev/2005-September/056846.html

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

http://mail.python.org/pipermail/python-dev/2005-September/056803.html

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.

regards
 Steve
-- 
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/