Proposed PEP for a Conditional Expression

[Terry Reedy]

"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
with
> the idea of introducing a conditional expression into Python. I
would
> welcome any discussion, suggestions, and/or help, sent either to
this
> 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,
ARG_22,
> and ARG_3 all make sense to me

Do you really find ARG_3 both unconvincing and sensible> or is there a
typo?

I suggest relabeling arguments A1, A2, ... (anti) and P1, P2,
...(pro).

> ------------------- DRAFT PEP
FOLLOWS ----------------------------------
> 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
version 1.)
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
out
>              is probably the best solution. It can be done in 4
line,
>              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
lambda
>              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
are always
         evaluated before the function is invoked. Thus, for instance,
the
         following would not work properly when a == 0:
         > x = cond( a==0, DEFAULT_VAL, 100/a )

        Next, the expression that ALMOST ALWAYS short-circuits
correctly:
        > 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
matches
        the conditional expression of C with (and,or) substituted for
(?,:).
        Because the boolean operators 'and' and 'or' short circuit,
this idiom
        works whenever a (or b) is certain to evaluate as true for all
values
        of the variables.  This is true of most (all?) realistic
examples given
        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
keys ]

        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])[0]
        > x = (c and (a,) or (b,))[0]
        These index into one-element sequences which are definitely
not false.
        The tuple version is slightly faster but more awkward to type
and read.
        > x = (c and (lambda:a) or (lambda:b))()
        Functions are also never false.  The version takes longer to
type
        and may be less readable, especiaoly within an outer lambda.

        In short, this PEP only proposes a new syntax and not a new
funtionality,
        and the argument for the new syntax must adress why such is
worth the
        accompanying costs.
..
>      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