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

[Paul Moore]

mis6 at pitt.edu (Michele Simionato) writes:

> I think the problem is not with the ternary operator, but with the abuse
> of "if".

It's not actually "abuse", but I do agree that the proposed syntax is
ugly.

> The C-like sintax
>
>  if (callable(obj)? obj(): default):

Guido's explicitly rejected this. There's no point in raising it.

> or the more pythonic "when"
>
>  if (when callable(obj) obj() else default):

As you write this - "when" expr1 expr2 "else" expr3 - it is
unparsable. Consider expr1 as "a + b" and expr2 as "- 1". Now, what
does

    when a + b - 1 else ...

parse as?

    when (a + b) (- 1) else ...
or
    when (a) (+ b - 1) else ...
???

Commas won't help, as they are used in tuple construction. You need a
keyword (such as "then") to go in there. Don't suggest mandatory
parentheses, please.

Can people please consider if their proposals are actually parseable?
Actually, the Python parser has some very strict constraints (1-token
lookahead) which mean that some things that *look* OK actually aren't,
but start from just basic parsability, at least.

> would be less confusing. I think introducing a ternary operator is
> worthwhile but one needs a new keyword to avoid confusion
> with the "if" statement.

Introducing a new keyword is a *much* more serious undertaking.

Things to remember:

1. This is *not* going into 2.3 (no new syntax in 2.3)
2. If a new keyword is required, at least 1 version preparation is
   required, in the form of a FutureWarning. See, for example, how
   "yield" was introduced.

So, without a new keyword, the PEP might get implemented in Python 2.4
(assuming the vote is positive). With a new keyword, it won't be until
Python 2.5 at the earliest (although it might be available in Python
2.4 via "from __future__ import").

And Guido doesn't like new kywords even for features he's in favour
of...

Paul.
-- 
This signature intentionally left blank