(partial) summary of ideas for the ternary operator

[Bengt Richter]

On 8 Feb 2003 13:50:08 -0800, mis6 at pitt.edu (Michele Simionato) wrote:
>Having read the thread on the ternary operator, I would like to comment
>some of the ideas that have been proposed and asking for new ones ;-)
[...]
>
>In summary, I would say the following:
>
> 1. After the introduction of functional programming constructs (lambda, 
>    map, etc), of list comprehension and of a boolean type in Python,
>    now there is more need for a ternary operator than ever.
>    I think Guido himself recognizes that since for the first time now
>    he is giving his disponibility to add a ternary operator.
>
>2. If we want a Pythonic (i.e. readable) ternary operator that even
>   newbies can understand, we have to pay a price: add a new kewyword
>   or new punctuation.
>
>3. If we stay with "if", abuses become easier. I think the original examples
>   of Guido were intended to point out these shortcomings. They improve a
>   little with the "when"/"?" notations:
>
>when C x else when D y else z   <=>  when C x else (when D y else z) 
>when C x or y else z         <=>  when C (x or y) else z 
>when C x else y or z         <=>  when C x else (y or z)  
>lambda : when C x else y     <=>  lambda : (when C x else y)  
>when C x else lambda : y     <=>  SyntaxError
>when C x else y,z            <=>  (when C x else y),z     
>x, when C y else z           <=>  x, (when C y else z)    
>
>C ? x else D ? y else z   <=>  C ? x else (D ? y else z) 
>C ? x or y else z         <=>  C ? (x or y) else z 
>C ? x else y or z         <=>  C ? x else (y or z)  
>lambda : C ? x else y     <=>  lambda : (C ? x else y)  
>C ? x else lambda : y     <=>  SyntaxError
>C ? x else y,z            <=>  (C ? x else y),z     
>x, C ? y else z           <=>  x, (C ? y else z)    
>
>4. I am willing to concede that in any proposal the ternary operator can be 
>   abused, and that it is less obvious than an if statement. 
>   Nevertheless, it is not a case that so many languages have a ternary 
>   operator: it is useful, and *can* be used without abusing it, if the 
>   programmer is a little of reasonable. Moreover, any of these proposals 
>   is better than the currently employed horrible hacks with and/or and 
>   [True,False][not condition]
>
>
>I am +0.5 for Guido's proposal, +1 for a proposal involving "when" or "?".
>Maybe "?" is better, since does not break old code never and it is
>clearer for C programmers (even for me, and I am not a C programmer ;);
>however it is less pythonic. 
>
>I am very curious of seeing the result of the final votation on the
>ternary operator. Happy discussion,
>
>
>                                         Michele
>
>P.S. the proposal by Holger Krekel's is not so bad,
>
>  s=sqrt(x) except x<0: 0
>
>since it has the advantage of avoiding the introduction of a new keyword and
>makes obvious which is the expected case. However, I don't like the abuse of
>colons, I would prefer the syntax
>
>  s=sqrt(x) except x<0 then 0
   s = x<0 -> 0 -> sqrt(x)   # see below for how this works
   s = x>=0 -> sqrt(x) -> 0  # same effect
>
>or something similar, but still it would be unclear on "if" statements:
>
>  if (sqrt(x) except x<0 then 0)>2: #disaster
   if (x>=0 -> sqrt(x) -> 0) >2: # rearranged should work too
>
>Waiting for other ideas ...

>From the Defending ... thread where I just wrote this:

"""
I confess to preferring mathematical-style notation in expressions.
I just had another idea ;-)
Maybe a variation on Paul's (IIRC) [cond -> expr; cond2 -> expr2; True -> expr3]
using '><' instead of ';' e.g.,

    cond -> exprT >< cond2 -> expr2 >< True -> exprF 

with a redundant final True condition and its '><' introducer being optional, e.g.
the basic ternary would pare down to:

    cond -> exprT -> exprF 
    
this could also have a default exprF if exprT is not followed by >< or ->.
What the default should be is another matter ;-)
"""

Trying it on Guido's examples copied from above
(though I think real examples should be used to get
a better feel for how things would look IRL):

>C ? x else D ? y else z   <=>  C ? x else (D ? y else z) 
 C -> x >< D -> y -> z     <=>  C -> x -> (D -> y ->z)

>C ? x or y else z         <=>  C ? (x or y) else z 
 C -> x or y -> z

>C ? x else y or z         <=>  C ? x else (y or z)  
 C -> x -> y or z

>lambda : C ? x else y     <=>  lambda : (C ? x else y)  
 lambda : C -> x -> y

>C ? x else lambda : y     <=>  SyntaxError
 C -> x -> lambda: y    # ok

>C ? x else y,z            <=>  (C ? x else y),z     
 (C -> x -> y), z       # parens necessary

>x, C ? y else z           <=>  x, (C ? y else z)    
 x, (C -> y -> z)       # parens necessary (to allow the ',' op precendence over the '->' op).

Note that you can chain conditional clauses indefinitely (of course if any cond always
evaluates to True, that kills anything following)

    result = (
           cond1 -> val1
        >< cond2 -> val2
        >< cond3 -> val3
        ...
        -> valDefault   # alternatively, ">< True -> valDefault"
    )

So your sqrt could have been any of:

    s = x<0 -> 0 -> sqrt(x)  
    s = x>=0 -> sqrt(x) -> 0  # same effect
    s = x>=0 -> sqrt(x) >< True -> 0  # same, with explicit final True condition

and even
    s = (
        x>=0 -> sqrt(x)
             -> 0
    )

I was partial to c ? x, y before I thought of this cond variant, but I like this better ;-)

Regards,
Bengt Richter