For review: PEP 308 - If-then-else expression
sross at connectmail.carleton.ca
Sat Feb 8 17:01:43 CET 2003
> +1 to "when". To me "if" is associated to the conditional statement, a
> conditional expression is a conceptually different thing and needs a
> different expression. Readability is worth adding a new keyword.
I agree with all of those points.
But, as others have posted, new keywords are non-starters in PEP talks.
(I especially enjoyed "contrariwise" (Andrew Koenig))
> P.S. I don't like your other proposal with the comma, my mind parses
> when C,x as the tuple when (C,x).
I also don't much care for my other suggestion, although I do not parse it
the way that you do.
Mostly, I just wanted to avoid a specific edge case someone mention much
earlier in the thread:
if x if C else y:
which just seemed ugly. But, then:
if x when C else y:
is only marginally less ugly. And, of course
if if C then x else y:
is worse than both. Oh, and then there's
if C ? x : y:
or, as was proposed earlier:
if C ? x else y:
None of the above constructs is particularly wonderful, none is particularly
clear, and, hopefully, none of them would ever be used. But, of those
listed, I find the 'when' variant to be the least confusing.
When I read "if x when C else y", the when causes me to backtrack in my
parsing, and reevaluate what I'm reading. For me,
it makes me stop and question what I'm actually reading. And, once again,
for me, it does this more strongly than the other variants.
For example, I tend to read the other variants as follows:
... do stuff...
... do stuff ...
In this case what you would want would be something that somehow reads
using if, evaluate expression x or expression y depending on condition C,
then depending on if's evaluation do stuff
(all very confusing, to be sure)
How can this be done both clearly and obviously? ... no idea...
Personally, I don't mind
if (y, x)[C]:
although I don't consider it to be either obvious or clear.
Anyway... I realize all of this does not follow the mains points in the
discussion so far, but it _is_ a possible outcome.
In the end, I see how a ternary operation can be useful, and how it can be
abused. What the discussion boils down to is this:
Do you need this construct enough to put up with the potential abuses it
Or, since its quite apparent that the construct is not strictly _needed_,
Do you _want_ this construct enough to put up with the potential abuses
it can bring?
Certainly, used appropriately, i.e., in a very simple and restricted form,
this construct would be pretty handy, but used inappropriately...this way
Whatever you choose is fine with me. If I don't like it I won't use it. If I
do like it I will use it sparingly.
But, if other people use it, I'll likely go mad... just kidding ...
More information about the Python-list