PEP308 - preference for 'x if c else y' over 'c then x else y'

[Stephen Horne]

On Fri, 14 Feb 2003 22:25:23 -0800, Erik Max Francis <max at alcyone.com>
wrote:

>Stephen Horne wrote:
>
>> The '... if ... else ...' version seems to have a natural
>> repetition-based pattern of growth which need not rely on obvious
>> nesting...
>> 
>>   x if c1 else y if c2 else z
>> 
>> OK, yes, it is nesting really - but, like the C 'else if', it reads
>> more like a continuation of the same thing than a nesting of one thing
>> in another.
>
>I really don't follow.  I would argue exactly the opposite:  Since
>if/else doesn't read left-to-right, the use of it for nesting (they're
>nesting both ways, however you want to look at it) is _more_
>strightforward on the strict left-to-right ordering of then/else than on
>the center-left-right one.  In the center-left-right one, it is harder
>to tell which condition belongs to what expressions due to the out of
>order pattern.

I actually kind of agree with you that 'x if c then y' seems a little
odd, even now that I've got used to it a bit more. But I don't really
agree with you on this.

You seem to be preoccupied with the order of evaluation - the fact
that the condition must be evaluated first, whereas only one of the
values to select from is evaluated at all.

I don't see things that way. I have more of a functional view of
expressions. In general, I think I shouldn't need to worry about the
order of evaluation - only about the meaning and the readability. In
expressions, evaluation order only makes a difference to the meaning
if there are side effects (except in that lazy evaluation can ignore
subexpressions which are not needed, but which might otherwise trigger
errors). Having functions with side effects is often considered bad
style, partly for this exact reason.

I'm not a fanatic about this. In C, I'm quite happy to write functions
whose whole purpose is in the side effects but which return a success
flag, and then I'll use short-circuit and operators to run a whole
sequence up to the first one that fails. It's a useful trick, it
works, and if the functions are well named it causes no surprises. But
it is also the exception rather than the rule. Algebra has rules of
commutativity and associativity. In general, I expect expressions to
behave the same way - especially in higher level languages.

>From the meaning/readability perspective, I think my point works
fairly well...

>>   x if c1 else y if c2 else z

The end result is always the one immediately left of the first
condition to pass (assuming an implicit always-passes condition after
the final else value). 

If evaluation order is more important to you, of course, I'm unlikely
to convince you - this is also probably why I'm happy to see lazy
evaluation with the same old function call notation while you are not,
which means my previous post on that missed the point a bit.

>All I see here is, "X strikes me as better than Y" -- which don't get me
>wrong, is a perfectly valid opinion -- but I really don't see any
>clarification of why.

I hope the why is now a little clearer, but it isn't really that big a
deal. I've read a lot of syntax proposals, but I don't think I read
any that discussed their readability when extended to select from
three or more values. I've raised the subject, which I thought was
worth doing.

Actually, my first choice would probably still be the function-call
syntax even though it would need obvious nesting to select from three
or more items. Then again... has anyone suggested something like...

  if (c1 : a, c2 : b, c3)

I suspect that could fit both of our mindsets - the syntax makes it
clear it's not a conventional function call, the lexical order matches
the evaluation order (for items that are evaluated), it grows in a
clear way, and it's concise. The colons would seem daft to me if it
only selected from two values, but they would vastly improve
readability when selecting from three or more values as they clearly
indicate the pairing between conditions and values in much the same
way as the pairing of keys and values in a dictionary. It probably
needs a tweak or two - I'm not sure if the leading 'if' keyword would
cause problems in the Python grammar, for example - but I think it has
some merit.

Of course I reserve the right to change my mind - there's certainly
plenty of ideas to choose from in this little brainstorming session!

-- 
steve at ninereeds dot fsnet dot co dot uk