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

Paul Moore gustav at
Sat Feb 8 21:44:33 CET 2003

Andrew Koenig <ark at> writes:

> The reason for +0.8 and not +1 is that I would prefer a syntax
> that doesn't evaluate right-to-left if someone can think of one.
> However, list comprehensions already have similar anomalies
> and they don't seem particularly bothersome.

Frankly, I think the proposed syntax is ugly. Every time I've seen an
example in a posting, I've needed to read it a couple of times to
comprehend it. And if I analyze my reasons, I'd say it's the
evaluation order. C's cond - trueval - falseval seems understandable,
whereas trueval - cond - falseval doesn't.

> I think this proposal is important because it significantly expands
> what one can do straightforwardly in the functional domain.  That is,
> I consider it to be in the same general category as lambda and list
> comprehensions -- features that not everyone will use, but that are
> important to the people who use them.

This is the most telling comment I've seen yet. I have little or no
interest in lambda, but I use list comprehensions often. On the other
hand, I've never missed conditional expressions while doing so. (But
when I see examples of list comprehensions using conditional
expressions, I can't immediately think of a "better" way of writing
them. Maybe I've just evolved a coding style which avoids the need.)

> My evidence that it is important is that (a) people keep asking for
> it; (b) people keep thinking up circumlocutions to accomplish the
> same thing; and (c) those circumlocutions are often either wrong
> or hard to understand or remember.

While these facts shouldn't be ignored, it's also important to
consider if maybe the *answers* to such requests shouldn't be
considered too. Earlier in the thread was a discussion of using
conditional expressions to make purals. There are two ways to address
this. The first is to offer other ways in Python to add an "s" if the
count is not 1. This fairly quickly proves the point that Python's
alternatives aren't as readable/convenient/whatever. The second way is
to point out that the algorithm doesn't work for a significant number
of cases (not all relating to I18N - consider "sheep", or "baby").
Then suggesting the use of a function makes much more sense. Even if
you never talk about mice in your application at the moment, the cost
is minor compared to the pain when the cheese consuming mammal
extension comes along in version 12...

This signature intentionally left blank

More information about the Python-list mailing list