For review: PEP 308 - If-then-else expression
James J. Besemer
jb at cascade-sys.com
Mon Feb 10 15:07:41 EST 2003
Andrew Dalke wrote:
> James J. Besemer:
>
>>David Eppstein wrote:
>>
>>
>>>Turn it around a little and both versions become a little clearer:
>>>
>>>"customer" if "spam" not in s else "vikings" if "eggs" in s else
>>>"waitress"
>>>
>>>if "spam" not in s:
>>> t = "customer"
>>>elif "eggs" in s:
>>> t = "vikings"
>>>else:
>>> t = "waitress"
>>
>
>>E.g., if you
>>look closely you'll find a subtle bug in the above if/else example. This
>>typo would be IMPOSSIBLE to make with inline choice. Thus the supposedly
>>"more readable" form admits a class of errors the inline form prohibits.
>
> And
>
>>this is a class of errors that easily go undetected in a declaration free
>>language like Python.
>
>
> What's the typo?
The typo was in a new code example I provided, and which was wrongly snipped
out of the above quote. Note the difference in leading quote indicator.
Following is my original comment (several paragraphs following) IN CONTEXT:
[... my cond example, contrasted with the buggy statement form: ]
targetVar1 = ( condition1
? ( condition2
? result1
: result2 )
: result3 )
Frankly, I find that verbosity in and of itself does not necessarily increase
the clarity of code and sometimes it's actually harmful. The fact that the
Python equivalent of the above expression is more lines and more typing does
not materially add to the clarity of expression (except if you happen to be
brainwashed to see things only that one way -- i.e. on a subjective level).
if condition1:
if condition2
targetVar1 = result1
else:
targetVarl = result2
else:
targetVar1 = result3
In fact, inline choice actually increases the clarity of the source code
because it emphasizes that "targetVar1" is necessarily the single target of
all possible sub expressions. In the if/else form the reader has to visually
verify that the target variables are all the same. In my experience, one
thing that best serves maintainability is to factor out common code wherever
possible. That way you avoid in advance the error prone process of having to
make identical changes to parallel sections of code. Because there's a
material savings even at the single statement level was one reason for
adopting augmented assignment. But the if/else form forces you to break this
rule.
More importantly, factoring out the redundant references to the target
variable the inline form prevents a class of common errors. E.g., if you
look closely you'll find a subtle bug in the above if/else example. This
typo would be IMPOSSIBLE to make with inline choice. Thus the supposedly
"more readable" form admits a class of errors the inline form prohibits. And
this is a class of errors that easily go undetected in a declaration free
language like Python.
So to flatly claim that the if/else form is superior to inline choice is
simply untrue. From the big picture standpoint, inline choice is equally
useful and understandable. Programmers can be trained to use and recognize
both forms as easily as just the one. Now, it's valid to say you prefer
if/else as a matter of personal taste. No accounting for taste. As a
manager, you can even enforce whatever standard you want in your coding style.
The utility for this construct is obvious and precedented. While I agree
that readability is important, it is specious to argue that this particular,
exceedingly minor change makes a material difference. As William Dode just
showed, it was much easier to explain to a non-programmer than list
comprehensions.
--
James J. Besemer 503-280-0838 voice
2727 NE Skidmore St. 503-280-0375 fax
Portland, Oregon 97211-6557 mailto:jb at cascade-sys.com
http://cascade-sys.com
More information about the Python-list
mailing list