For review: PEP 308 - If-then-else expression

James J. Besemer jb at
Sun Feb 9 11:22:53 CET 2003

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"
> But really, the reason for the unreadability of all of these forms is 
> that they make no sense -- they're built up of seemingly random strings 

Even corrected, Andrew's example does illustrate a weakness of the 
right-to-left proposal: it does not readily amean itself to proper 
indentation as does the left-to-right, condition first form.  IMHO this 
constitutes an argument for placing the condition before the alternatives, 
rather than an argument against the construct altogether.

Whenever I do have occasion to use inline choice, I always fully parenthesize 
and "properly" indent the sub expressions, for maximum clarity:

     targetVar1 = ( condition1
                      ? ( condition2
                          ? result1
                          : result2 )
                      : result3 )

This is every bit as clear as the equivalant statement long-hand; it's 
virtually the same.  This convention preserves the notion that the first 
token on every line is a big clue as to what's going on with the rest of the 
line and that you can see the overall structure from the indentation.

Frankly, I find that verbosity in and of itself does not necessarily increase 
  the clarity of code and more often 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
                 targetVarl = result2
         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 

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 


James J. Besemer		503-280-0838 voice
2727 NE Skidmore St.		503-280-0375 fax
Portland, Oregon 97211-6557	mailto:jb at	

More information about the Python-list mailing list