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

[Albert van der Horst]

In article <mailman.1483.1270240598.23598.python-list at python.org>,
Steve Holden  <steve at holdenweb.com> wrote:
>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.

Let's look at a c-example.
    stamp =  weight>=1000 ? 120 :
             weight>=500  ? 100 :
             weight>=250  ? 80  :
             weight>=100  ? 60  :
                 44;

In a glance I see that stamp gets a value.
This wouldn't be so with regular if-statements that defines
numerous path's through the code that each must be tested.
Then I find this eminently suited to compare to a table given
as a specification.

What is akward is the definition of the ternary
operation that is left associative to mean
    stamp =  weight>=1000 ? 120 :
             (
                     weight>=500  ? 100 :
                     (
                             weight>=250  ? 80  :
                             (
                                     weight>=100  ? 60  :
                                      44
                             )
                     )
             ) ;
And not

    stamp =  ((((( weight>=1000 ? 120 : weight>=500 ) ? 100 : weight>=250 )
                 ? 80   ...

Now Python

    stamp =( 120 if  weight>=1000 else
             100 if  weight>=500  else
             80  if  weight>=250  else
             60  if  weight>=100  else
             44  )

This has the same advantage as c, plus :
        - the prices line up
        - there is no way to misinterpret associativity
          (anyway you put the brackets don't change meaning)

So I like it!
Old hands would have ...
    stamp =( weight>=1000 and  120 or
             weight>=500  and  100 or
             weight>=250  and  80  or
             weight>=100  and  60  or
                               44  )

(Kind of a brain twister, I think, inferior to C, once the c-construct
is accepted as idiomatic.)

<SNIP>

>
>regards
> Steve

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert at spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst