PEP 308: Precendence of "a then b else c"
hst at empolis.co.uk
Thu Feb 13 12:53:50 CET 2003
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).
This message has been checked for all known viruses by the MessageLabs Virus Scanning Service.
More information about the Python-list