[Python-Dev] Adding C ternary select (a?b:c) to Python?

[Tim Peters]

[Christopher Petrilli]
> ...
> Python is not a language that has been optimized for "minimal
> typing", it's much more verbose than most languages, and so that
> argument shouldn't be applied.

Concise expression of common concepts is a Good Thing, though, and there's
nothing inherently evil about wanting one of two outcomes <wink>.  My
impression is that the people historically most in favor of ?: ("or
something like it") are also the ones most strongly in favor of embedded
assignment ("or something like it"), and I can't *dismiss* either gripe.
The Python

while 1:
    x = something_or_other()
    if not x:
        break
    consume(x)

idiom is truly grating at first -- more so than the multi-line ?:
alternatives, in my eyes.

> Perhaps it's for optimization?  That was I believe the original
> argument made for it in K&R, in that optimizers in that day were rather
> antiquated, wheras today, I believe that any C compiler would get it
> right if it were expressed in its full form. (Timbot?)

Indeed, a couple weeks ago we tracked down a "mysterious slowdown" of our
core speech recognizer to a particular compiler failing to optimize *unless*
we changed a ?: into a long winded if/else!  There's really nothing you can
say about "any C compiler" -- optimization is much more a black art than
anyone in that business will admit to in public <0.9 wink>.

C was definitely designed with "by hand" optimization in mind, and,
ironically, it's those features (particularly pointer aliasing) that make it
harder for compilers to optimize than is, say, Fortran.

But regardless of origin, ?: stands or falls on its other merits now.
Python's own implementation uses it often enough, and to good effect.  So it
can't be that Guido hates the idea <wink>.  It's just hard to love the
syntax.

> So, it comes down to a few questions for me:
>
> 	Does it solve a new problem?	No
> 	Is it pythonic?			No
> 	Does it make it faster?		No

Would a nice syntax allow clearer expression of some common computations?
Probably yes.  That's the same basis on which, e.g., list.pop and
list.extend and dict.get and 3-argument getattr and ... were adopted.
"Faster" applied to those too, but nobody pushed for 'em on that basis.
Clearer!  That's what really matters.  It's the same argument for list
comprehensions too.

> ...
> Sorry if I pushed someone's buton, but... I saw a lot of hints at making
> Python MUCH more complex, which is counter to why I changed and dropped
> many other languags.

A good antitode to feature panic is reviewing Misc/HISTORY:  Guido's
willingness to entertain suggestions far exceeds his willingness to adopt
them <wink>.

it-would-be-different-if-features-were-just-as-easy-to-
    take-out-ly y'rs  - tim