PEP-308 a "simplicity-first" alternative

[Dave Brueck]

On Wed, 12 Feb 2003, Tim Hochberg wrote:

> >>On the contrary, the question is whether to replace the current idiom
> >>_with_new_syntax_. Not adopting new syntax does not stand in the way of
> >>declaring the and/or idiom to be bad form and standardizing on a new
> >>idiom or idioms.
> >
> >
> > Such as _______________? This topic has come up over and over for years
> > and nobody has come up with a better idiom than the one listed in the FAQ.
> > Unless a better one is discovered then the choice really is between
> > sticking with the old one or replacing it with new syntax. If you can
> > think up a better idiom, now would be an excellent time to suggest it.
>
> If what you want is a terse, short-circuiting idiom for the ternary
> operator I can't help you. But it's been asserted, and as far as I can
> tell accepted by both sides, that short-circuiting is not needed often
> in ternary operations.

Side question: in your opinion, why did Guido say he would reject
proposals that lacked short circuiting?

> Doctor-it-hurts-when-I-do-this-Then-don't-do-it'ly yours,

That's how I feel when I need the conditional operator but don't have it,
and instead have to resort to what I consider to be ugly workarounds that
have little to do with the _intent_ of my code. I miss it from C because
it _expresses what I mean_ whereas:

{True:x, False:y}[bool(C)]

very obviously does not.

-Dave