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

[Erik Max Francis]

Paul Moore wrote:

> Erik Max Francis <max at alcyone.com> writes:
>
> > Paul Moore wrote:
> >
> > > (expression1, expression2)[bool(condition)]
> >
> > This is not short circuiting and, furthermore, has the expressions
> > reversed.
> 
> It's not short circuiting, as I said myself below. Don't be obtuse.

But you also missed the important point that the conditions were
reversed (the "evaluate as true" expression goes is the _second_ element
of the tuple; the "evaluate as false" is the _first_).  This
demonstrates the inutility of these workarounds:  It's not clear what
they want to do, they have flaws, and it's easy to get them wrong.

But people want the functionality of conditional expressions, so they
will use these constructs.  They will make code less readable and more
prone to error.

> > > (condition and (lambda: expression1) or (lambda: expression2))()
> >
> > Sure, but they're unreadable.
> 
> By whose definition? That's the key point. I've said over and over
> again that it's all subjective.

Of course they're subjective.  Any classification such as "readable,"
"elegant," etc. is going to be subjective.  If there weren't subjective
elements to this debate it wouldn't still be going on.

> I agree to the extent that I find them unreadable.

And that was my point.  The solutions you offer are unreadable
(subjectively), over a very wide range of subjective opinions:  even
yours.  Suggesting them as alternatives and then asking, "Now why do you
really want a conditional operator if you already have these?" seems,
well, silly.  You know damn well why:  I (we) think they're unreadable,
and even you agree subjectively that they're unreadable.

> > The point is that people want this functionality.
> 
> *Some* people.
> 
> The other point is that *some* people *don't* want this functionality.
> With the same level of conviction as those who do.

Yes, obviously.  The point here is that both sides make their case so
that the BDFL can make a judgement call.  We're just making our
(subjective) case.

> OK, that definition only lacks an explanation of "horribly
> unreadable".  I guess it makes you +1 on the introduction of a
> conditional expression, but I have no idea of your position on the
> proposed syntax.

The problem with selecting a preferred syntax is that there are extra
parameters in the choice that make some more preferable than others. 
The introduction of new keywords is eschewed, so forms I might prefer
(like `if p then x else y', parentheses required or not) are out of the
running before we get started.  Or are they?  I don't know how strong
the BDFL's objection to new keywords (and one like `then', which seems
unlikely to be commonly used in code to me; I've specifically avoided it
myself _because_ it looks like a keyword) are, but I bet they're
stronger than his objection to the use of : in `p ? x : y' (one I'd
agree with for Python), since colons are already used for important
syntactical and this is a non-analogous application).

So the choice of the alternate syntax really depends on how strong his
objections are to each other, and how wedded he is to those
prohibitions.  We don't know those weights, so it makes it hard to say
"I want _this_ syntax here (and, should the main vote pass, know it will
be an option)."

I would be willing to settle for `x if p else y'.

> So far, I'd admit I'm hard to please. So what? You are too - you've
> rejected at least 6 suggested alternatives (and/or, dict lookup,
> boolean indexing, lambda, if statement, helper function).

The issue isn't about alternatives.  There are _always_ alternatives
(such as the single-element list or the lambda trick).  The question is
whether those alternatives are worse than the disease.

In each of the real-world suggestions that have been proposed, the
anti-conditional operator crowd has missed the whole point by saying,
"Well, you could just do this instead."  Of course you could; there are
myriad ways of writing the same code.  The question is whether those
examples stand as more readable than the alternatives on their face.  I
think that for some of the examples they do, and that's why I support
the addition of a conditional operator.

If you're inherently against the addition of a conditional operator in
absolute terms, then you will _always_ find the non-conditional forms
(which no one ever denied existed) more preferable.

I've actually seen some opponents of the PEP (I don't believe it was
you, so I'm not suggesting you are responsible) insist that the
proponents show them a form where a conditional operator is _absolutely
required_.  We all have to know that no such form exists; Python is
expressive enough that there will always be an alternative formulation;
if there weren't, conditional operators would already be in the
language.  That's not the point, and it naver has been.

-- 
 Erik Max Francis / max at alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/  \ Life is an effort that deserves a better cause.
\__/ Karl Kraus
    Alcyone Systems / http://www.alcyone.com/
 Alcyone Systems, San Jose, California.