PEP 308: Pep Update

[Damien Morton]

Id like to propose the desireability of any proposed conditional selection
expression syntax to handle multiple chained condition/value pairs.

For the leading options offered, chaining them looks like this:

STRICT INTERPRETATION

(if <cond1>: <expr1> else: (if <cond2>: <expr2> else: <expr3>))
(<cond1> then <expr1> else (<cond2> then <expr2> else <expr3>))
(<cond1> ? <expr1> : (<cond2> ? <expr2> : <expr3>))

RELAXED INTERPRETATION

(if <cond1>: <expr1> elif: <cond2>: <expr2> else: <expr3>)
(<cond1> then <expr1> elif <cond2> then <expr2> else <expr3>)
(<cond1> ? <expr1> : <cond2> ? <expr2> : <expr3>)

Id also like to mention my own proposal ("generalising the ternary
operator"):

(<cond1> ? <expr1> , <cond2> ? <expr2> , <expr3>)


"Raymond Hettinger" <vze4rx4y at verizon.net> wrote in message
news:6qH2a.32424$F25.27498 at nwrddc02.gnilink.net...
> Amended the PEP to reflect some convergence on the newsgroup:
>
> * Listed the downsides of the current proposal.
>
> * Listed why '<cond> then <expr1> else <expr2>' is starting to
>    be preferred over '<cond> and <expr1> or <expr2>'.
>
> * After BDFL comments, I withdrew my c??a||b syntax
>    and deleted the rejected c?a!b syntax.  The remaining
>    punctuation based contender is c?a:b.
>
> * After BDFL rejection of non-short-circuiting options,
>    advocacy dropped sharply.  Removed it from the list of
>    contenders.
>
> The leading options on the table are:
>
> *     (if <cond>: <expr1> else: >expr2>)
> *     <cond> then <expr1> else <expr2>
> *     <cond> ? <expr1> : <expr2>
> *     no change
>
>
> Raymond Hettinger
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>