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

[Paul Moore]

Andrew Koenig <ark at research.att.com> writes:

> holger> Maybe Roman Suzi (IIRC) has found one (short-circuiting)
>
> holger>     cond -> (true_expr, false_expr)
>
> holger> which i am currently thinking about.  
>
> I'm not thrilled about this example because if you cover up the
> "cond ->" part, you get what looks like a tuple, and tuples don't
> short-circuit.

I dislike this suggestion because it's too punctuation-heavy. On the
other hand, I think I dislike all the keyword suggestions (including
Guido's) because they are too text-heavy. Go figure.

If anything convinces me, I imagine it will be some form of
punctuation-based approach, which doesn't re-use parentheses, or
commas. Introducing new syntactic tokens (like ->) may work best for
me.

But I don't know what the implications will be in terms of the
introduction process (keywords are out, at least in part because a new
keyword requires a 2-version lead time - I don't think the question of
new tokens like -> has *ever* come up...)

>
> I'd be happy with
>
>         true_expr if cond else false_expr

I dislike this for the order, and for the keyword-heaviness. (Nothing
new, I've said this before).

> but must confess that I'm growing more in favor of
>
>         if cond: true_expr else: false_expr
>
> even though it looks like an if statement -- or perhaps *because*
> it looks like an if statement.

I dislike this a *lot*. Colons are only used in statement forms in
Python at the moment. I don't think this should change...

[Oops, I just remembered lambda. I accept that it invalidates the
statement above, in a logical sense, but for some reason, that makes
no difference to my feelings. I honestly don't know why, maybe it
*is* nothing more than prejudice, but I suspect that if we were
arguing about syntax for lambda, I'd want something different there
too...]

> I don't think there's any real ambiguity from the compiler's
> viewpoint, because "if" denotes a statement only when it is the first
> token of the statement and an expressin otherwise.

There is a fundamental ambiguity. An expression *is* a statement. But
the "if expression" does *not* require newlines in the same places as
the if statement.

Consider

    if cond: f(0) else: f(1)

Currently this is invalid Python (you need a newline before the "else"
to make it a valid if statement). With an if expression as you
propose, it becomes a perfectly valid expression statement, which
makes one of two function calls.

While the *semantics* would be identical to the if statement form
(with the added newline), I would imagine that it would be absolute
hell to parse this correctly, given that Python's parser is fairly
stupid (IIRC, it's a simplistic LL(1) parser with only one token
lookahead), and that's a *feature*. Past discussions on python-dev
have shown Guido to be strongly against constructs which require the
parser to become smarter.

[It's easy enough to imagine rules on how to disambiguate this, but I
suspect they would cont as needing compiler smarts]

> I also don't think that there's any real ambiguity from the
> programmer's viewpoint, because the meaning is conceptually the
> same for expressions as for statements.

I didn't try very hard to find an example which was confusing to the
programmer, but I'm sure you could find some. In the first instance,
in the statement above, try explaining to a novice (or even an
expert!) why changing "f(0)" to "x = f(0)" requires you to insert an
extra newline!

Yup, on reflection, this one sucks.
Paul.
-- 
This signature intentionally left blank