PEP 308: Erik's alternatives list

Erik Max Francis max at alcyone.com
Tue Feb 18 21:59:31 EST 2003


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.]

DISCLAIMER:  The dividing line between "seconded" and "unseconded"
schemes (II and III above) is fairly subjective; I'm really going by
whether anyone other than the original proponent expressed interest in
it, no matter how many times it was proposed.  No special meaning or
insult should be read into a proposal being classified under III instead
of II; they are simply my personal impression based on the reading of
these threads, and an attempt to separate "things people seemed to like"
from "things people didn't seem to like."

MORE DISCLAIMERS:  This is list has no authoritative weight whatsoever;
it's just a list I've been personally maintaining since these threads
started.  No significance should be paid to the ordering of alternatives
in each section, though they are in rough chronological order (in the
order that _I_ saw them, but even that is not a significant guideline). 
No attempt is made to weigh the pros or cons of each proposal here,
although some clarification of the form itself is warranted in a few
cases, and that is done with footnotes.  Also, for safety's sake, no
mention whatsoever of the original proponent is made here; several forms
were suggested independently by several people over time, some having
even been proposed long before PEP 308 was created, potentially making
giving proper credit problematic (the forms should stand on their own,
anyway, regardless of who proposed them).  Noticeably and consciously
absent from this list are forms which do not meet the criteria set forth
in PEP 308, namely those which do not support short circuiting behavior;
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
forms have been proposed with or without required parentheses
surrounding them; since this has happened for multiple forms over the
debate, for the sake of brevity I will not distinguish between them here
and will only list the unparenthesized forms (but when non-parentheses
punctuation is proposed or the parentheses are an intrinsic part of the
notation, they will of course be included).  Finally, only genuinely new
syntaxes are listed here.

The following symbols are used consistently:  C represents the
conditional expression which is always evaluated, x represents the
expression to be evaluated if the conditional is true, and y represents
the expression to be evaluated if the conditional is false.  So, for
example, the conditional operator from C (and C++, Java, Perl, etc.)
would be written C ? x : y.

Here is the list:

I.  Proposals mentioned in the PEP at some point

1.  x if C else y
2.  if C then x else y
3.  if C: x else: y
4.  C ? x : y
5.  C ? x ! y
6.  cond(C, x, y)                                                    (*)
7.  C ?? x || y
8.  C then x else y

II.  Proposals which were "seconded"

1.  x when C else y
2.  C ? x else y
3.  C -> x else y
4.  C -> (x, y)
5.  [x if C else y]
6.  ifelse C: x else y                                              (**)
7.  <if C then x else y>
8.  C and x else y

III.  Proposals but were not "seconded"

1.  x @ C or else y
2.  C if? x else y
3.  y or x if C
4.  |x if C else y|
5.  when C then x otherwise y
6.  C ? (x, y)
7.  C -> x -> y
8.  C then: x else: y
9.  C ? x, y
10. (? C: x, y ?)

Footnotes:

* This `cond' is a special form, not simply a builtin function, which
lazily evaluates its last two arguments (depending on the value of the
first, which _is_ evaluated).  There were also variations on the name of
the special form itself.

** Several alternative names for the starting keyword `ifelse',
including `select', `when', and `case'.

-- 
 Erik Max Francis / max at alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/  \ Many situations can be clarified by the passing of time.
\__/ Theodore Isaac Rubin
    CSBuddy / http://www.alcyone.com/pyos/csbuddy/
 A Counter-Strike server log file monitor in Python.




More information about the Python-list mailing list