Proposed PEP for a Conditional Expression
tjreedy at home.com
Sun Sep 9 22:08:21 CEST 2001
"Michael Chermside" <mcherm at destiny.com> wrote in message
news:mailman.1000046772.19777.python-list at python.org...
> Included in this email is a PEP which I am putting together dealing
> the idea of introducing a conditional expression into Python. I
> welcome any discussion, suggestions, and/or help, sent either to
> newsgroup under this topic, or emailed to me at <python at mcherm.com>.
I'll do both
> PEP, I find ARG_1, ARG_3, and ARG_23 unconvincing, while ARG_21,
> and ARG_3 all make sense to me
Do you really find ARG_3 both unconvincing and sensible> or is there a
I suggest relabeling arguments A1, A2, ... (anti) and P1, P2,
> ------------------- DRAFT PEP
> PEP: NO-NUM-YET
> Title: Creating a Short-Circuiting Conditional Expression
> ARG_1: Workarounds exist.
It's really hard to fairly present arguments you find 'unconvincing',
so I will help you.
(Please note: I am impressed at how well you did do, especially for
I'm going to split this into two anti arguments, A1 and A2, and one
pro argument, P1.
A1: Python has conditional statements for conditional assignments.
> > if c:
> > x = a
> > else:
> > x = b
> Of course, many people would say that just writing it
> is probably the best solution. It can be done in 4
> or in 2, like this:
> > if c: x = a
> > else: x = b
P1. In either case, though, this is NOT an expression, so
> using it may require creating a temporary variable and
> splitting a formula into two lines, or replacing a
> expression with a named function.
A2: Python already has short-circuiting conditional expressions (even
if some proponents of an alternative syntax refuse to recognize them
as such by dismissing them as 'workarounds').
First, the conditional expression that DOESN'T short-circuit:
> def cond(c, a, b):
> if c: return a
> else: return b
> x = cond(c, a, b)
This fails to short-circuit because arguments to a function
evaluated before the function is invoked. Thus, for instance,
following would not work properly when a == 0:
> x = cond( a==0, DEFAULT_VAL, 100/a )
Next, the expression that ALMOST ALWAYS short-circuits
> x = c and a or b # or, almost equivalently
> x = (not c) and b or a
The advantage of this simple form is that it syntactically
the conditional expression of C with (and,or) substituted for
Because the boolean operators 'and' and 'or' short circuit,
works whenever a (or b) is certain to evaluate as true for all
of the variables. This is true of most (all?) realistic
by proponents of a new syntax. Examples:
> inverses = map( lambda x: x==0 and "Inf" or 1.0/x, values )
> tags = [ (s is not None and '<%s>' % s or None) for s in
If it is possible that both a and b can evaluate to 'false',
there are clumsier
but GUARENTEED-TO-WORK forms:
> x = (c and [a] or [b])
> x = (c and (a,) or (b,))
These index into one-element sequences which are definitely
The tuple version is slightly faster but more awkward to type
> x = (c and (lambda:a) or (lambda:b))()
Functions are also never false. The version takes longer to
and may be less readable, especiaoly within an outer lambda.
In short, this PEP only proposes a new syntax and not a new
and the argument for the new syntax must adress why such is
> ARG_21: Simplifies lambda expressions.
> ARG_22: Makes a functional style easier.
> ARG_24: Clarifies intent when used for assignments.
All of these are arguments for the use of expressions rather than
statements. They all apply equally well to the existing expression
forms. They are not, in themselves, arguments for a new form.
> ARG_23: Lots of people ask for it.
> Lots of people ask for a conditional expression.
Some are ignorant of the current forms, some deny that they are what
they are, and some want something we do not currently have (a simple
form without cruft, like C's, that always works) but have not settled
on anything specific for the rest of us to consider. I hope this
'PEP' helps all three groups.
Terry J. Reedy
More information about the Python-list