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

[Paul Moore]

Erik Max Francis <max at alcyone.com> writes:

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

No I'm not. I'm pointing out that it *is* implied. I'd like it made
explicit. And that includes your definition of "horrible". Preferably
(so that Andrew's happy) in a completely objective form.

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

It's not short circuiting, as I said myself below. Don't be obtuse.

And I never claimed that expression1 was the true form. But that's
perilously close to *me* being obtuse, so I'll just say that which way
round the expressions go is irrelevant to *my* argument. (It may not
be to yours - if you want to try to claim that false before true is
objectively "horrible").

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

By whose definition? That's the key point. I've said over and over
again that it's all subjective.

I agree to the extent that I find them unreadable. But I would rewrite
using if *statements* rather than conditional expressions (possibly by
defining a helper function). I'm not suggesting that approach here,
because I'm assuming you'd classify that as "horrible". (But I can't
see how you'd justify such a statement - maybe there's another implied
qualification that we still need to tease out?)

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

Those who suggest these forms don't intend for them to be used in
contexts where they are wrong - or by people too inexperienced to know
they are wrong.

I've seen people in favour of the PEP get its version wrong, too...

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

> Whether or not there's a standard, clear way to do it, they will
> resort to such hideous atrocities as the ones above.

Anyone who uses "atrocities" just to avoid the extra statements that
not using a conditional expression needs is, frankly, not worth either
my or your time to consider. Such people will find ways of writing bad
code no matter what we do.

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

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.

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

OK, so the fundamental disagreement could be characterised as about
what constitutes "wholly unreadable".

I'm -1 on the whole thing, not because I don't see uses for a
conditional expression, but because I've yet to see a proposal which I
find attractive enough to justify the change.

So show me something that *I* don't find "wholly unreadable", and I'll
switch my vote.

But remember that

1. I don't have problem with admitting that "wholly unreadable" is a
   subjective concept, and specifically I don't know what I'd classify
   as acceptable until I see it. So "yuk" may be as much of an
   explanation of why I don't accept something as I can manage.
2. I'm not excluding a rewrite using helper functions or statement
   level "if" from what I consider an "alternative". It's you doing
   that, so you need to demonstrate that your proposal is better than
   that (not just "as good as", but "better").

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

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

As I say, it was - I just wanted to emphasize it, mainly because
Andrew Koenig has been making a big deal of the "fact" that the "no"
voters are using totally subjective arguments, whereas the "yes"
voters have objective reason on their side. As you can imagine, I find
that suggestion a little annoying...

Paul.
-- 
This signature intentionally left blank