Vote on PEP 308: Ternary Operator

[lynx]

i'm not sure if i get a vote in matters like these, but i've never let
such details stop me from running my mouth before... i happen to really
like the ternary operator in those languages i know that has it, and i
wouldn't mind seeing some form of it in python - *if* it could be added
without confusing the syntax and readability of the language as a whole.

i don't like it enough to ask for anything that'd just end up unreadably
messy, or that would stand out like a sore thumb looking nothing like the
rest of the language. i'm already leery of using list comprehensions
simply because the aesthetics of that syntax, in my subjective view, don't
"look like python" enough for my tastes; they remind me of inline assembly
or SQL in C or somesuch.

oh, and your proposed ballot is too confusing and complicated for me to
figure out. i could perhaps write a voting front-end for it, but that
doesn't seem worth the effort, so i'll just post a rambling commentary to
the 'net instead; i'm more familiar with that...

On Sun, 02 Mar 2003 02:25:46 +0000, Raymond Hettinger wrote:

> CHOICES (taken from Erik Max Francis's posting of seconded choices)
> -------
> A.  x if C else y

sortof reminds me of Perl's reverted "if/unless" syntax. i could deal with
it, but too much turning the "usual" order of the conditional and
consequent inside out takes mental effort to read.

> B.  if C then x else y

this one i would heartily support. probably my favourite out of these. if
parenthesizing the conditional and possible consequents turns out to be
necessary, i wouldn't mind that either.

> C.  (if C: x else: y)

much the same as (B), only terser. maybe just a bit too terse, the
previous form seems more explicit about what it is and what it does.

> D.  C ? x : y
> E.  C ? x ! y

variations on the "standard" C-or-Perl-style ternary. i don't mind this
style at all - _in a language where ALL the code looks like that_. in
python, this would stand out, at least to my aesthetic sensibilities. i
wouldn't like it.

> F.  cond(C, x, y)

shades of reduce(), map() or similar functional-ish constructs. i don't
mind having those in the language, but i don't use them much, either. i'd
probably use this, but maybe not as frequently as i might other syntaxes.

> G.  C ?? x || y

all the disadvantages of options (D) and (E), without their advantage in
terseness. no thanks.

> H.  C then x else y

eer.. i had to read that one twice to see what it said. something tells me
i'd keep on having to do that, so no thanks.

> I.  x when C else y

more of the inside-out logic of (H) and (A). _i_ find it mildly confusing,
but this form still isn't too bad. maybe i could live with it, but IMAO
this isn't the best option.

> J.  C ? x else y
> K.  C -> x else y
> L.  C -> (x, y)

see (G) above.

> M.  [x if C else y]
> N.  ifelse C: x else y
> O.  <if C then x else y>

and these just get ever weirder and weirder... how would you tell (M)
apart from a regular list comprehension? and introducing a new meaning for
angle brackets like (O) would, well, it just somehow upsets me. sorry, no
thanks.

> P.  C and x else y

ah, one i could get to like! this would be my runner-up candidate if
option (B) didn't make it; i'd have a hard time deciding between this and
(F), but likely i'd go for this. again, if parenthesizing the conditional
and/or consequents is necessary, i'd be fine with that.

> Q.  any write-in vote

i can't think of anything that would be markedly better or worse than
what's been presented, so i'll shut up now.

-- 
   PGP/GnuPG key (ID 1024D/3AC87BD1) available from keyservers everywhere
    Key fingerprint = FA8D 5EA4 E7DC 84B3 64BC  410C 7AEE 54CD 3AC8 7BD1
                "...if you can fill the unforgiving minute
                with sixty seconds' worth of distance run..."