python-peps/pep-0308.txt

PEP: 308
Title: If-then-else expression
Version: $Revision$
Last-Modified: $Date$
Author: Guido van Rossum and Raymond D. Hettinger
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 7-Feb-2003
Post-History: 7-Feb-2003


Introduction

    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 I am the author of this PEP, I am neither in favor
    nor against this proposal; it is up to the community to decide.
    If the community can't decide, I'll reject the PEP.


Proposal

    The proposed syntax is as follows:

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


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

    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.

    Note: 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

    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.

    ---

    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.

    ---

    David Ascher proposed a variant that doesn't have this problem:

        <condition> ? <expression1> ! <expression2>

    While cute, this suffers from the Perlish problem of using
    arbitrary punctuation with an arbitrary meaning; and it's no
    easier to understand than the ?: form.

    ---

    Raymond Hettinger proposed a variant that removes the
    arbitrariness:

            <condition>  ??  <expression1>  ||  <expression2>

    The ?? and || are not arbitrary as they strongly suggest testing
    and alternation.  Another merit is that that existing operators
    are not overloaded.  Having two characters at each step also
    helps visually separate  the subordinate expressions.  Alas,
    the BDFL prefers the proposed syntax and considers this as
    alternative number one.

    ---

    Many people suggest adding a new builtin instead of extending the
    syntax of the language, e.g.:

        ifelse(<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.


Summary of the Current State of the Discussion

    Groups are falling into one of five camps:

    1.  Adopt a ternary operator built using punctuation characters.
	It would look something like:
	    <condition> ?? <expression1>  || <expression2>

    2.  Adopt a ternary operator built using existing keywords.
	The proposal listed above is the leading example.

    3.  Adopt a ternary operator built using a new keyword.
        The leading contender looks like this:
	    cond(<condition>, <expression1>, <expression2>)							 

    4.  Adopt a function without short-circuit behavior:
            cond(<condition>, <expression1>, <expression2>) 

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

    The third form introduces a new keyword and arranges the arguments
    separated by commas.  Adding a new keyword is to be generally avoided.
    But the form is clear, short, and direct.  There is a possible
    confusion with function syntax which implies that all the arguments
    are evaluated rather than short-circuited.  This idea was presented
    by the BDFL and should be considered a contender for the final vote.
    The exact keyword is still an open question.  One proposal was iif(),
    but it looks like a typo and can be confused with if-and-only-if
    which has a different, well-defined mathematical meaning.

    The fourth position is much more conservative.  Adding a new
    function, cond(), is trivially easy to implement and fits easily
    within the existing python model.  Users of older versions of
    Python will find it trivial to simulate.  The downside is that
    it does not provide the sought-after short-circuit
    evaluation (see the discussion below on the need for this).
    The bigger downside is that the BDFL opposes *any* solution that
    does not provide short circuit behavior.

    The last position is doing nothing.  Arguments in favor include
    keeping the language simple and concise; maintaining backwards
    compatibility; and that any every use cases 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, visually unappealing workarounds.

    It should also be mentioned that most supporters of any of the
    first four positions do not want an imperfect solution
    and would sooner have no change than create a wart to attain
    their desired functionality.


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 the 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 counter point 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.

    Still, the point is moot since the BDFL opposes solutions
    which do not provide short-circuit behavior.


Copyright

    This document has been placed in the public domain.



Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End: