(a==b) ? 'Yes' : 'No' [Python]

Prev: Binary Decimals in Python
Next: Python Script Creator/Generator (function factory)

From: kj on 2 Apr 2010 16:12

In <mailman.1326.1269971785.23598.python-list(a)python.org> Steve Holden <steve(a)holdenweb.com> writes:

>John Nagle wrote:
>> Chris Rebert wrote:
>>> On Tue, Mar 30, 2010 at 8:40 AM, gentlestone <tibor.beck(a)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.

"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.)

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.

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.)

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"...

~K

From: John Bokma on 2 Apr 2010 16:20

kj <no.email(a)please.post> writes:

> 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"...

Perl has something that has IMO somewhat the same problem:

print "Hello, world!\n" if $some_condition;

I prefer most of the time:

$some_condition and print "Hello, world!\n";

Or even:

$some_condition
and print "Hello, world!\n";

Moreover, instead of:

$x = 'some value' unless defined $x;

I prefer

defined $x
or $x = 'some value';

I read the latter as: $x must be defined, otherwise some value must be
assigned to it, like a precondition.

YMMV,

--
John Bokma j3b

Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

From: Steve Holden on 2 Apr 2010 16:35

kj wrote:
> In <mailman.1326.1269971785.23598.python-list(a)python.org> Steve Holden <steve(a)holdenweb.com> writes:
>
>> John Nagle wrote:
>>> Chris Rebert wrote:
>>>> On Tue, Mar 30, 2010 at 8:40 AM, gentlestone <tibor.beck(a)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/

From: Patrick Maupin on 2 Apr 2010 16:48

On Apr 2, 3:12 pm, kj <no.em...(a)please.post> wrote:
> Is that for real??? It's the QWERTY rationale all over again. Swell..

Well, bearing in mind that everybody seems to have an agenda, so you
can't (or shouldn't, anyway) take all your news from a single source,
it may be that the common wisdom about the QWERTY thing is incorrect:

http://reason.com/archives/1996/06/01/typing-errors

I have to confess that I haven't done any real deep research on the
subject, but yet again, we find there is more than one side to a
story.

Regards,
Pat

From: Ethan Furman on 2 Apr 2010 16:54

First | Prev | Next | Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13
Prev: Binary Decimals in Python
Next: Python Script Creator/Generator (function factory)