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

Dave Brueck dave at
Sat Feb 8 20:22:05 CET 2003

On Sat, 8 Feb 2003, holger krekel wrote:

> Actually, in my book people gave quite some good reasons
> for opposing the PEP:
>     a) it reads ugly especially in non-assignment statements

But this is entirely subjective - obviously you can have that opinion, but
in and of itself it carries no more weight than the opposing opinion that
it reads well. :)

>     b) it reuses a keyword which formerly was a clean indicator
>        of a statement

Hmm... do most people really think "I see an 'if', a statement is
coming!"? Or do they think "I see an 'if', a decision is coming"? I
imagine it's the latter, and as others have mentioned, the if-statement
form currently handles the higher-level control flow (branching) as well
as the lower-level choice-making that would sometimes be handled by

>     c) you can't read it either LtR or RtL

Sure you can. In English, for example, it makes perfect sense to say "buy
the apples, if they're ripe, otherwise buy the grapes". Same thing. IMO
the trouble grokking if-then-else expressions is due to being unfamiliar
with them, and not some inherent readability problem.

>     d) there are often better ways than doing the C-ish
>        'x ? y : z'

Nobody disagrees with this. The point of the PEP is simply that
the current Python-ish:

  if x:
   y = w
   y = z

could often be better expressed with an if-expr.

>     e) adds to the stuff you have to learn if you read others code

Very true, but to be honest it's *much* easier to figure this out on your
own than, say, a generator. And I think this point is key: a newbie who is
unfamiliar with if-exprs actually has a *very* good chance of figuring out
what it means. I actually like the C-style conditional operator because
I'm used to it, but the PEP as proposed has a better chance of being
understood by the uninitiated because the keywords used in it have the
_same meaning_ as they do in other contexts. IOW, if you look at it
and guess what it means you'll probably guess correctly, *far* more so
than, say:

x = filter(None, seq)

>     f) is not an important enough use case to warrant new syntax

This may or may not be true - we have no way to measure it either way.


More information about the Python-list mailing list