PEP 308: Precendence of "a then b else c"

[Harvey Thomas]

Anders J. Munch wrote:
> 
> "Raymond Hettinger" <vze4rx4y at verizon.net> wrote:
> > The leading options on the table are:
> > 
> > *     <cond> then <expr1> else <expr2>
> 
> What's the precedence of this thing?
> 
> For example, what do each of these mean:
>    a + b then c else d
>    a then b else c + d
>    a and b then c else d
>    a then b else c and d
>    a, b then c else d
>    a then b else c, d
>    lambda: a then b else c
> 
> - Anders
> 
When, what seems like tens of thousands of postings ago PEP 308 was first released, I was +1 on some form of ternary operator being introduced, but I'm now down to +0 and as things go will end as -0 or even -1.

The most unadorned form of a conditional expression is

condition truevalue falsevalue

which is nearly unreadable without keywords/punctuation separating the three items.
With some proposals put forward there is possibility for confusion if colons, particularly as in else: are used as I can imagine it's not always going to be clear whether a code fragment is part of an if/elif/else statement construct or a conditional expression.

A possibility that avoids all ambiguity would be

when condition then truevalue otherwise falsevalue

the examples above would be (guessing at the precedence required some):
    a + when b then c otherwise d    or a + (when b then c otherwise) d
>   when a then b otherwise c + d
>   when a and b then c otherwise d
>   when a then b otherwise c and d
>   a, when b then c otherwise d
>   when a then b otherwise c, d
>   lambda: when a then b otherwise c


but this introduces three keywords (could reduce to two if else was used instead of otherwise) and is quite wordy - even COBOL like (I think, I haven't written any COBOL for thirty years). 

Harvey




_____________________________________________________________________
This message has been checked for all known viruses by the MessageLabs Virus Scanning Service.