PEP 308: Erik's alternatives list

[Bengt Richter]

On Tue, 18 Feb 2003 18:59:31 -0800, Erik Max Francis <max at alcyone.com> wrote:

>Since PEP 308 discussion is winding to a close (as Raymond's post
>indicated), I'm hereby disclosing the full list of conditional operator
>proposal alternatives that I've been trying to keep tabs on since the
>threads first began.  Note that I've attempted to include every form
>here, including those I personally dislike, no matter how strongly.  If
>it got mentioned as an alternative, it's listed here.
>
>I'm dividing the list into three categories:  proposals that have been
>mentioned in the PEP, even if withdrawn later (I); proposals that have
>been suggested in the newsgroup and have been "seconded" in the sense of
>having met with some tangible support (II); proposals that have been
>suggested but are "unseconded" in that they did not appear to receive
>any independent support (III).  [I also have a list of more generalized
>schemes -- which could be used as degenerate conditional operators --
>but as they are really not appropriate for the PEP at hand and open up a
>huge can of worms, I will not mention them here.]
A can of worms is good for fishing ;-) Why load prejudice so heavily against
general capability? IMO if a particular ternary syntax generalizes well
into an n-ary form, that is a strength that ought to be considered when
voting. E.g., you've included

    c -> x -> y

but there's no way to see that as the minimal ternary form of

    c1 -> expr1 .. c2 -> expr2 .. c3 -> expr3 .. True -> exprDefault

I.e., that the single condition plus default of

    c -> x .. True -> y

simplifies to

    c -> x -> y

given ".. True" as an implicit final condition if omitted before the "->")

[...]
>additionally, as mentioned above, more generalized schemes (say, an
>expressionalized switch...case construct, or macros) are not mentioned
>here either.  Further, only the simplest case of each form is shown here
>for clarity; the n-ary forms are not mentioned.  Additionally, several

IMO if a particular syntax forcloses on the possibility of a reasonable/readable
n-ary generalization in a future PEP, that is a disadvantage that ought to
be made apparent to voters, even if the PEP does not currently go beyond
a simple ternary. Also simple ternaries can be compounded legally, and IMO
how the syntax looks and reads compounded ought to be shown to voters, not
just left to Guido to explore and evaluate for himself (though, thank goodness,
I am sure he can be trusted to look into those things).

I would welcome a list that shows both ternary and n-ary versions as two
or three lines per version, e.g.,

    c -> x -> y
    c1 -> expr1 .. c2 -> expr2 .. c3 -> expr3 .. True -> exprDefault

    c ? x : y
    c1 ? expr1 : c2 ? expr2 : c3 ? expr3 : exprDefault

Why not?

Regards,
Bengt Richter