For review: PEP 308 - If-then-else expression

[Erik Max Francis]

Paul Moore wrote:

> Following on from Andrew Koenig's observations on "interesting aspects
> of this discussion", I note a lot of people who are in favour of
> conditional expressions are making comments along these lines (ie "I
> want conditional expressions and will take any form I can get").
> 
> This worries me. I'd like to see a little more concern for the overall
> integrity of the Python language.

I think you're missing the implied conditional of something that isn't
horrible.

> Actually, if I was feeling perverse, I could argue that the following
> comes under the category of "any form I can get":
> 
>     (expression1, expression2)[bool(condition)]

This is not short circuiting and, furthermore, has the expressions
reversed.

> Or, if you need evaluation of only one of the expressions:
> 
>     (condition and (lambda: expression1) or (lambda: expression2))()
> 
> Strangely, you can get these forms now.

Sure, but they're unreadable.  Other forms are slightly more idiomatic
(but still not immediately obvious), such as `p and x or y', but these
have problems (this doesn't work right if x is false).

The point is that people want this functionality.  Whether or not
there's a standard, clear way to do it, they will resort to such hideous
atrocities as the ones above.  The FAQ even attests to this (although I
get the impression it attempts to do so by demonstrating how nuts the
solutions are; I think that subtlety backfires).  The point is that
people _do_ write `p and x or y' even though it is not obvious to
everyone that the intent is emulating a conditional operator and has a
flaw (if x is false).

People want it, people will use emulations that are hard to read,
flawed, or both.  They're not in the language now; if it is ultimately
decided that a conditional operator will not be added to the language,
then people will continue to ask for it, continue to read the FAQ entry
on it, and continue to use emulations that hard to read, flawed, or
both.

> Can you qualify exactly what you are willing to accept?

A standard form of conditional operator that isn't horribly unreadable. 
It should support short circuiting, since if you're going to introduce a
conditional operator, there's no value in not making it so.

To make an analogy with the Boolean PEP (sorry, the number doesn't occur
to me immediately), some of us wanted a Boolean type.  That was a case
where the typename, true constant, and false constant (bool, True,
False) were pretty obvious so there wasn't a whole lot of debate about
what form it should take, but I'll wager that most people in favor of
putting Booleans in the language wouldn't have minded much if they were
spelled (bool, true, false) or (Boolean, TRUE, FALSE) or some
variation.  The point is they wanted the feature, they'd be satisfied
with anything as long as it was 1. built into the language and thus
standard and 2. not obtuse and horrible.  (In the case of adding
Booleans, the choice was almost completely without dispute, but you get
the idea.)

I see very much the same thing happening here.  It's far more important
to me that a proper short circuiting conditional operator get added to
the language than the precise details of what it looks like, provided
it's not wholly unreadable.

> This position is inconsistent. You don't like the forms that currently
> exist. (Don't get me wrong, I don't either - but I am not arguing for
> a conditional expression to be added to the language).

The implied "and something that doesn't suck" has always been there,
sorry it wasn't obvious.

-- 
 Erik Max Francis / max at alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/  \ Always forgive your enemies -- nothing annoys them so much.
\__/ Oscar Wilde
    Bosskey.net: Quake III Arena / http://www.bosskey.net/q3a/
 A personal guide to Quake III Arena.