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

Andrew Koenig ark at
Sat Feb 8 18:07:05 CET 2003

holger> a) it reads ugly especially in non-assignment statements

ark> Subjective.

holger> "Beautiful is better than ugly."

But what is beautiful and what is ugly is still subjective.
I think that

        if x > 0.0:
	    y = math.sqrt(x)
	    y = 0.0

is ugly compared to

        y = math.sqrt(x) if x > 0.0 else 0.0

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

>> Subjective, especially when you realize that "if" is already thus
>> reused in list comprehensions.

holger> Still "Readability counts."

And readability is often subjective.  Anyway, it would still be true that
a statement is an if statement whenever its first token is "if".

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

>> Agreed, but that's not an argument against PEP 308 unless you
>> change "often" to "always".

holger> "Special cases aren't special enough to break the rules."

Although practicality beats purity.
holger> e) adds to the stuff you have to learn if you read others code

>> Agreed, but the importance of that is subjective.

holger> Sure, why not use perl, then? 

A sufficient reason for me is the lack of orthogonality in Perl's
type system.

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

>> Subjective.

holger> Now I wonder what you might deem not to be subjective.  
holger> I guess that the "design prinicples" of python in


holger> are mostly subjective categories, too, then.  
holger> That's ok but i *like* them :-)

What I deem not subjective is statements like:

     Here's an example of how I'd like to use this feature.
     Without it, I have to do it this way.  Which form do you prefer?

In another (long) message in this thread, I did just that for a
2800-line C program that I wrote 20 years ago.  What those examples
show is how one programmer used ?: in practice.  Readers can then
judge for themselves whether the use of ?: gained or lost on balance.

More information about the Python-list mailing list