PEP 308: ternary operator

[Dan Bishop]

Terry Hancock <hancock at anansispaceworks.com> wrote in message news:<DPF5a.1$cD5.2347 at newsread2.prod.itd.earthlink.net>...
> Dan Bishop wrote:
> > It's not too hard to remember.  As someone else has already pointed
> > out, the question mark follows the "question" (cond).  The three parts
> > of the expression are also in exactly the same order as the normal
> > "if(<cond>) <stmt a> else <stmt b>" construct.
> 
> I was just trying to point out that it was not really intuitive.
> 
> The fact that you need to explain it, is evidence enough to me,
> and I figure that if it has confused me before, that it will confuse others.

That applies equally to many of the constructs already in Python.

> >> I therefore would like to voice support for either of the following
> >> "new-keyword" options:
> >> 
> >> d = <a> when <cond> else <b>
> > 
> > Yuck!
> 
> Expressive,  but unhelpful towards understanding *why* you don't like it. 
> ;-D

1) It reads too much like p*rl's trailing if/unless.

2) It makes it more awkward to convert a statement if-else to an
expression if-else and vice-versa.

3) [See my response to the next paragraph.]

> I like "when" for several reasons. Not least is that when some unsuspecting 
> newbie hits this in my code, they will immediately know this is a new 
> construct, and be able to look it up under "when" where they will get 
> correct information.

But if they have to look it up, then, by your own definition, doesn't
this make "when" unintuitive?

If "<cond> ? <a> : <b>" were introduced, then most C/C++/Java/C#
programmers wouldn't have to look it up.  If "(if <cond>: <a> else:
<b>)", then many Python programmers could figure out the meaning by
analogy to the statement form of if-else.

Also, have you ever noticed that all selection functions in other
languages (or spreadsheets, or CAS's) use the same order?

Derive: IF(<cond>, <a>, <b>)
Excel: IF(<cond>, <a>, <b>)
Lisp: (cond (<cond> <a>) (t <b>))
TI-89 BASIC: when(<cond>, <a>, <b>)
VB: iif(<cond>, <a>, <b>)

The a-cond-b order is familiar to no one.

> But the most obvious reason is that it reads as fairly correct English:

> d = a when c else b
> Set d to a when c, else [set it to] b.
> 
> d == a when c else b
> Compare d to a when c, else [compare it to] b.

Wait!  Shouldn't that be interpreted as (d == a) when c else b?

> But the main thing I was trying to say is that I don't like the 
> symbol-based syntaxes.  To me, they really feel out of place in Python.
> That's true of the C-based syntax, but also of the other symbol syntaxes.

So instead of writing the symbol-based "x *= 2", we should write
"Multiply x by two."?  I wouldn't like that at all.