PEP-308 a "simplicity-first" alternative

[Bengt Richter]

On Wed, 12 Feb 2003 17:41:53 GMT, Tim Hochberg <tim.hochberg at ieee.org> wrote:
[...]
>in ternary operations. So if nothing comes of the current discussion, 
>the warning against "a and b or c" in the FAQ can be strengthened and 
>people can be pointed to either:
>
># Clear, extensible, but verbose
>result = {True: true_value, False : false_value}[cond]
># More concise
>result = [true_value, false_value][not cond]
>
>In my own experience the common "[false_value, true_value][cond]" is 
>error prone because the ordering of the values is opposite what I'd 
>expect, so I wouldn't recomend that.
Not to mention that 'not' guarantees 0 or 1.

>
>When short circuiting is required, I have no problem telling people to 
>suck it up and use a a real if/else statement since this case is 
>relatively rare. To quote M. Hudson quoting Tim Peters "learn to love 
>the return key".
I think I have an answer:

    result = cond and {true_value} or false_value

where {x} means x is treated as True in logical expression context, but its
value is preserved for the expression value. An optional variant is

    result = cond and {true_value} or {false_value}

Regards,
Bengt Richter