PEP 308: "then" "else" for deprecating "and" "or" side effects

[Mike Orr]

The tertiary operator is one of those long-requested features that's
not going to go away, because it's genuinely useful and allows one to
eliminate an entire if-block, the way a list comprehension eliminates
an entire for-block.  Rejected or not, the tertieary operator will
continue to be a FAQ, so we may as well put it in the language now so
the issue will go away.  That's what we did for '+=' and string
methods, which were rejected for years for pedantic reasons (+= as
unnecessary, string methods because "immutable objects don't have
methods").  Python has always been great in adding, not every feature,
but a few well-chosen features that have wide applicability.  The
tertiary operator would be a good complement.  (Sets and dict
comprehensions are two others; fortunately, sets are already here. :)

Christian Tismer <tismer at tismer.com> wrote in message news:<mailman.1045192739.6092.python-list at python.org>...
> "and" and "or" are two-headed beasts:
> At first glance, they pretend to be logical operators.
> At second inspection, they do this logic by promoting
> one of their operands.

... which leads to the frustrating situation that they are "almost" a
tetiary operator but with a sneaky little gotcha.

    result = a and b or c
    # Whoops, 'b' is false.  My result is wrong!

The fact that people try to use 'and ... or' so broadly for this shows
that something is missing.  Only one little tweak is needed: an
alternative construct that faithfully returns 'b' if 'b' is false.
 
> Due to the presence of a real boolean type, we
> should ask ourselves if "and" and "or" shouldn't be
> deprecated in their current meaning, towards being
> "boolean only"?
> I think it would be nicer if "and" and "or" would only
> produce true or false. But this would break lots of code.

'and' and 'or' are fine as they are.

    result = replyVar or DEFAULT
    # I want DEFAULT if replyVar is '', 0 or None.  What's wrong
    # with that?  If it ain't broke, don't fix it.

    result = conditionA and conditionB
    # A true boolean.  Who cares what exactly 'result' is as long as 
    # it works properly in an 'if' statement.  One can always use
    # bool(result) if one really wants 'True'.

Now, on to syntaxes.  I like these:

1)    result = b if a else c
      # Advantage: parallel to list comprehension syntax.

2)    result = a ? b : c
      # Similar to C/Perl/PHP.  This is arguably more readable 
      # than (1).

3)    result = a ?? b || c
      # Good visual separation.  
      # Disadvantage: irritating to C/Perl programmers, for 
      # whom these operators have an entirely different meaning.

4)    result = a then b else c

I don't like these:

A)    result = if a then b else c
      # Too polymorphic.  Let's avoid expressions that "almost" look 
      # like statements, for the same reason '=' is not allowed in 
      # expressions.

B)    result = if (a) then (b) else (c)
      # This would be the only time Python requires '()' except for 
      # 1-tuples.