PEP-308 a "simplicity-first" alternative

[Paul Rubin]

Christian Tismer <tismer at tismer.com> writes:
> Maybe it could be easier to understand (and to attach
> according precedence) with
> 
> x then y else z
> 
> But this has the drawback of a new keyword.
> So, if the list likes the x and y else thing, I'll second it.

I intensely dislike "x and y else z".  "Explicit is better than
implicit" to me specifically means avoiding this type of cutesy
overloading.

"x then y else z" is ok with me, as are "x => y else z", "x ? y else z",
"x ? y : z", and so forth.  I'm not crazy about "y if x else z", but
at least it's explicit.