In <mailman.1326.1269971785.23598.python-l...@python.org> Steve Holden
<st...@holdenweb.com> writes:
>John Nagle wrote:
>> Chris Rebert wrote:
>>> On Tue, Mar 30, 2010 at 8:40 AM, gentlestone <tibor.b...@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
--
http://mail.python.org/mailman/listinfo/python-list
