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