PEP: 308 Title: Conditional Expressions Version: $Revision$
Last-Modified: $Date$ Author: Guido van Rossum, Raymond Hettinger
Status: Final Type: Standards Track Content-Type: text/x-rst Created:
07-Feb-2003 Python-Version: 2.5 Post-History: 07-Feb-2003, 11-Feb-2003

Adding a conditional expression

On 9/29/2005, Guido decided to add conditional expressions in the form
of "X if C else Y".[1]

The motivating use case was the prevalence of error-prone attempts to
achieve the same effect using "and" and "or".[2]

Previous community efforts to add a conditional expression were stymied
by a lack of consensus on the best syntax. That issue was resolved by
simply deferring to a BDFL best judgment call.

The decision was validated by reviewing how the syntax fared when
applied throughout the standard library (this review approximates a
sampling of real-world use cases, across a variety of applications,
written by a number of programmers with diverse backgrounds).[3]

The following change will be made to the grammar. (The or_test symbols
is new, the others are modified.)

    test: or_test ['if' or_test 'else' test] | lambdef
    or_test: and_test ('or' and_test)*
    ...
    testlist_safe: or_test [(',' or_test)+ [',']]
    ...
    gen_for: 'for' exprlist 'in' or_test [gen_iter]

The new syntax nearly introduced a minor syntactical backwards
incompatibility. In previous Python versions, the following is legal:

    [f for f in lambda x: x, lambda x: x**2 if f(1) == 1]

(I.e. a list comprehension where the sequence following 'in' is an
unparenthesized series of lambdas -- or just one lambda, even.)

In Python 3.0, the series of lambdas will have to be parenthesized,
e.g.:

    [f for f in (lambda x: x, lambda x: x**2) if f(1) == 1]

This is because lambda binds less tight than the if-else expression, but
in this context, the lambda could already be followed by an 'if' keyword
that binds less tightly still (for details, consider the grammar changes
shown above).

However, in Python 2.5, a slightly different grammar is used that is
more backwards compatible, but constrains the grammar of a lambda used
in this position by forbidding the lambda's body to contain an
unparenthesized condition expression. Examples:

    [f for f in (1, lambda x: x if x >= 0 else -1)]    # OK
    [f for f in 1, (lambda x: x if x >= 0 else -1)]    # OK
    [f for f in 1, lambda x: (x if x >= 0 else -1)]    # OK
    [f for f in 1, lambda x: x if x >= 0 else -1]      # INVALID

References

Introduction to earlier draft of the PEP (kept for historical purposes)

Requests for an if-then-else ("ternary") expression keep coming up on
comp.lang.python. This PEP contains a concrete proposal of a fairly
Pythonic syntax. This is the community's one chance: if this PEP is
approved with a clear majority, it will be implemented in Python 2.4. If
not, the PEP will be augmented with a summary of the reasons for
rejection and the subject better not come up again. While the BDFL is
co-author of this PEP, he is neither in favor nor against this proposal;
it is up to the community to decide. If the community can't decide, the
BDFL will reject the PEP.

After unprecedented community response (very good arguments were made
both pro and con) this PEP has been revised with the help of Raymond
Hettinger. Without going through a complete revision history, the main
changes are a different proposed syntax, an overview of proposed
alternatives, the state of the current discussion, and a discussion of
short-circuit behavior.

Following the discussion, a vote was held. While there was an overall
interest in having some form of if-then-else expressions, no one format
was able to draw majority support. Accordingly, the PEP was rejected due
to the lack of an overwhelming majority for change. Also, a Python
design principle has been to prefer the status quo whenever there are
doubts about which path to take.

Proposal

The proposed syntax is as follows:

    (if <condition>: <expression1> else: <expression2>)

Note that the enclosing parentheses are not optional.

The resulting expression is evaluated like this:

-   First, <condition> is evaluated.
-   If <condition> is true, <expression1> is evaluated and is the result
    of the whole thing.
-   If <condition> is false, <expression2> is evaluated and is the
    result of the whole thing.

A natural extension of this syntax is to allow one or more 'elif' parts:

    (if <cond1>: <expr1> elif <cond2>: <expr2> ... else: <exprN>)

This will be implemented if the proposal is accepted.

The downsides to the proposal are:

-   the required parentheses
-   confusability with statement syntax
-   additional semantic loading of colons

Note that at most one of <expression1> and <expression2> is evaluated.
This is called a "short-circuit expression"; it is similar to the way
the second operand of 'and' / 'or' is only evaluated if the first
operand is true / false.

A common way to emulate an if-then-else expression is:

    <condition> and <expression1> or <expression2>

However, this doesn't work the same way: it returns <expression2> when
<expression1> is false! See FAQ 4.16 for alternatives that work --
however, they are pretty ugly and require much more effort to
understand.

Alternatives

Holger Krekel proposed a new, minimally invasive variant:

    <condition> and <expression1> else <expression2>

The concept behind it is that a nearly complete ternary operator already
exists with and/or and this proposal is the least invasive change that
makes it complete. Many respondants on the newsgroup found this to be
the most pleasing alternative. However, a couple of respondants were
able to post examples that were mentally difficult to parse. Later it
was pointed out that this construct works by having the "else" change
the existing meaning of "and".

As a result, there is increasing support for Christian Tismer's proposed
variant of the same idea:

    <condition> then <expression1> else <expression2>

The advantages are simple visual parsing, no required parentheses, no
change in the semantics of existing keywords, not as likely as the
proposal to be confused with statement syntax, and does not further
overload the colon. The disadvantage is the implementation costs of
introducing a new keyword. However, unlike other new keywords, the word
"then" seems unlikely to have been used as a name in existing programs.

---

Many C-derived languages use this syntax:

    <condition> ? <expression1> : <expression2>

Eric Raymond even implemented this. The BDFL rejected this for several
reasons: the colon already has many uses in Python (even though it would
actually not be ambiguous, because the question mark requires a matching
colon); for people not used to C-derived language, it is hard to
understand.

---

The original version of this PEP proposed the following syntax:

    <expression1> if <condition> else <expression2>

The out-of-order arrangement was found to be too uncomfortable for many
of participants in the discussion; especially when <expression1> is
long, it's easy to miss the conditional while skimming.

---

Some have suggested adding a new builtin instead of extending the syntax
of the language. For example:

    cond(<condition>, <expression1>, <expression2>)

This won't work the way a syntax extension will because both expression1
and expression2 must be evaluated before the function is called. There's
no way to short-circuit the expression evaluation. It could work if
'cond' (or some other name) were made a keyword, but that has all the
disadvantages of adding a new keyword, plus confusing syntax: it looks
like a function call so a casual reader might expect both <expression1>
and <expression2> to be evaluated.

Summary of the Current State of the Discussion

Groups are falling into one of three camps:

1.  Adopt a ternary operator built using punctuation characters:

        <condition> ? <expression1> : <expression2>

2.  Adopt a ternary operator built using new or existing keywords. The
    leading examples are:

        <condition> then <expression1> else <expression2>
        (if <condition>: <expression1> else: <expression2>)

3.  Do nothing.

The first two positions are relatively similar.

Some find that any form of punctuation makes the language more cryptic.
Others find that punctuation style is appropriate for expressions rather
than statements and helps avoid a COBOL style: 3 plus 4 times 5.

Adapting existing keywords attempts to improve on punctuation through
explicit meaning and a more tidy appearance. The downside is some loss
of the economy-of-expression provided by punctuation operators. The
other downside is that it creates some degree of confusion between the
two meanings and two usages of the keywords.

Those difficulties are overcome by options which introduce new keywords
which take more effort to implement.

The last position is doing nothing. Arguments in favor include keeping
the language simple and concise; maintaining backwards compatibility;
and that any every use case can already be already expressed in terms of
"if" and "else". Lambda expressions are an exception as they require the
conditional to be factored out into a separate function definition.

The arguments against doing nothing are that the other choices allow
greater economy of expression and that current practices show a
propensity for erroneous uses of "and", "or", or one their more complex,
less visually unappealing workarounds.

Short-Circuit Behavior

The principal difference between the ternary operator and the cond()
function is that the latter provides an expression form but does not
provide short-circuit evaluation.

Short-circuit evaluation is desirable on three occasions:

1.  When an expression has side-effects
2.  When one or both of the expressions are resource intensive
3.  When the condition serves as a guard for the validity of the
    expression.

    #  Example where all three reasons apply
    data = isinstance(source, file)  ?  source.readlines()
                                     :  source.split()

1.  readlines() moves the file pointer
2.  for long sources, both alternatives take time
3.  split() is only valid for strings and readlines() is only valid for
    file objects.

Supporters of a cond() function point out that the need for
short-circuit evaluation is rare. Scanning through existing code
directories, they found that if/else did not occur often; and of those
only a few contained expressions that could be helped by cond() or a
ternary operator; and that most of those had no need for short-circuit
evaluation. Hence, cond() would suffice for most needs and would spare
efforts to alter the syntax of the language.

More supporting evidence comes from scans of C code bases which show
that its ternary operator used very rarely (as a percentage of lines of
code).

A counterpoint to that analysis is that the availability of a ternary
operator helped the programmer in every case because it spared the need
to search for side-effects. Further, it would preclude errors arising
from distant modifications which introduce side-effects. The latter case
has become more of a reality with the advent of properties where even
attribute access can be given side-effects.

The BDFL's position is that short-circuit behavior is essential for an
if-then-else construct to be added to the language.

Detailed Results of Voting

    Votes rejecting all options:  82
    Votes with rank ordering:     436
                                  ---
    Total votes received:         518


            ACCEPT                  REJECT                  TOTAL
            ---------------------   ---------------------   -----
            Rank1   Rank2   Rank3   Rank1   Rank2   Rank3
    Letter
    A       51      33      19      18      20      20      161
    B       45      46      21      9       24      23      168
    C       94      54      29      20      20      18      235
    D       71      40      31      5       28      31      206
    E       7       7       10              3       5       32
    F       14      19      10              7       17      67
    G       7       6       10      1       2       4       30
    H       20      22      17      4       10      25      98
    I       16      20      9       5       5       20      75
    J       6       17      5       1               10      39
    K       1               6               4       13      24
    L               1       2               3       3       9
    M       7       3       4       2       5       11      32
    N               2       3               4       2       11
    O       1       6       5       1       4       9       26
    P       5       3       6       1       5       7       27
    Q       18      7       15      6       5       11      62
    Z                                               1       1
            ---     ---     ---     ---     ---     ---     ----
    Total   363     286     202     73      149     230     1303
    RejectAll                       82      82      82      246
            ---     ---     ---     ---     ---     ---     ----
    Total   363     286     202     155     231     312     1549

CHOICE KEY

    A.  x if C else y
    B.  if C then x else y
    C.  (if C: x else: y)
    D.  C ? x : y
    E.  C ? x ! y
    F.  cond(C, x, y)
    G.  C ?? x || y
    H.  C then x else y
    I.  x when C else y
    J.  C ? x else y
    K.  C -> x else y
    L.  C -> (x, y)
    M.  [x if C else y]
    N.  ifelse C: x else y
    O.  <if C then x else y>
    P.  C and x else y
    Q.  any write-in vote

Detail for write-in votes and their ranking

    3:  Q reject y x C elsethenif
    2:  Q accept (C ? x ! y)
    3:  Q reject ...
    3:  Q accept  ? C : x : y
    3:  Q accept (x if C, y otherwise)
    3:  Q reject ...
    3:  Q reject NONE
    1:  Q accept   select : (<c1> : <val1>; [<cx> : <valx>; ]* elseval)
    2:  Q reject if C: t else: f
    3:  Q accept C selects x else y
    2:  Q accept iff(C, x, y)    # "if-function"
    1:  Q accept (y, x)[C]
    1:  Q accept          C true: x false: y
    3:  Q accept          C then: x else: y
    3:  Q reject
    3:  Q accept (if C: x elif C2: y else: z)
    3:  Q accept C -> x : y
    1:  Q accept  x (if C), y
    1:  Q accept if c: x else: y
    3:  Q accept (c).{True:1, False:2}
    2:  Q accept if c: x else: y
    3:  Q accept (c).{True:1, False:2}
    3:  Q accept if C: x else y
    1:  Q accept  (x if C else y)
    1:  Q accept ifelse(C, x, y)
    2:  Q reject x or y <- C
    1:  Q accept (C ? x : y) required parens
    1:  Q accept  iif(C, x, y)
    1:  Q accept ?(C, x, y)
    1:  Q accept switch-case
    2:  Q accept multi-line if/else
    1:  Q accept C: x else: y
    2:  Q accept (C): x else: y
    3:  Q accept if C: x else: y
    1:  Q accept     x if C, else y
    1:  Q reject choice: c1->a; c2->b; ...; z
    3:  Q accept [if C then x else y]
    3:  Q reject no other choice has x as the first element
    1:  Q accept (x,y) ? C
    3:  Q accept x if C else y (The "else y" being optional)
    1:  Q accept (C ? x , y)
    1:  Q accept  any outcome (i.e form or plain rejection) from a usability study
    1:  Q reject (x if C else y)
    1:  Q accept  (x if C else y)
    2:  Q reject   NONE
    3:  Q reject   NONE
    3:  Q accept  (C ? x else y)
    3:  Q accept  x when C else y
    2:  Q accept  (x if C else y)
    2:  Q accept cond(C1, x1, C2, x2, C3, x3,...)
    1:  Q accept  (if C1: x elif C2: y else: z)
    1:  Q reject cond(C, :x, :y)
    3:  Q accept  (C and [x] or [y])[0]
    2:  Q reject
    3:  Q reject
    3:  Q reject all else
    1:  Q reject no-change
    3:  Q reject deliberately omitted as I have no interest in any other proposal
    2:  Q reject (C then x else Y)
    1:  Q accept       if C: x else: y
    1:  Q reject (if C then x else y)
    3:  Q reject C?(x, y)

Copyright

This document has been placed in the public domain.

[1] Pronouncement
https://mail.python.org/pipermail/python-dev/2005-September/056846.html

[2] Motivating use case:
https://mail.python.org/pipermail/python-dev/2005-September/056546.html
https://mail.python.org/pipermail/python-dev/2005-September/056510.html

[3] Review in the context of real-world code fragments:
https://mail.python.org/pipermail/python-dev/2005-September/056803.html