FW: [Python-Dev] conditional expressions?

[Paul Moore]

On 16 Oct 2001 00:12:41 GMT, m.faassen at vet.uu.nl (Martijn Faassen) wrote:

>But these are just vague responses. Perhaps I'll get used to them
>pretty quickly. What do others think? Excuse me if I missed somekind
>of long thread about this and I'm repeating the often stated. :) 

I don't have a particular problem with the if ... then ... else expression. It's
a little wordy, but it feels fairly Pythonic - keep it clear, even if it is less
terse than it could be.

And in reality, I don't think there'll be a *practical* issue with the
expression - people can abuse it, but they most likely won't. Any more than they
do with lambda expressions, or list comprehensions, or...

However, I do have some serious reservations about the parenthesis issue.
Guido's rule "parens are not required except to disambiguate" sounds reasonable
in isolation, but in practice, it's not at all obvious what counts as ambiguous.
And it glosses over the fact that ambiguity is treated as a *syntax error* -
something with no parallel anywhere else in Python's expression syntax, to my
knowledge.

In the message Tim quoted from Guido, there are only two examples of required
parentheses:

>    (if 1 then 2 else 3) + 4

If this is a full statement, that's fine - if as the first token in a statement
must be a statement-if, not an expression-if. But if this is a fragment, as in

    x = (if 1 then 2 else 3) + 4

then I don't see any need for the parens. They promote readability, sure - but
they shouldn't be *mandatory*. Precedence should apply. I recall seeing a quote
from Guido to the effect that "else" gobbles up everything to the end of the
expression - OK, so the precedence of "if 1 then 2 else 3 + 4" is "if 1 then 2
else (3 + 4)". No problem. But *don't* make it illegal, just because it's not
obvious. I haven't a *clue* what precedence applies to lambda, but I can be sure
I'd never have a problem with it - I'd just parenthesize. This is the same.

>    a[(if i then 2 else 3) : 4]

Again, the relative binding strengths of if...then...else and : should assign a
meaning to the unparenthesized form. I'm not implying that omitting the
parentheses is good style, but it shouldn't be illegal.

As for Guido's cases where he isn't sure,

>    if (if 1 then 2 else 3): pass
>    print (if 1 then 2 else 3)
>    for i in (if 1 then "abc" else "def"): pass

I see no reason to make the unparenthesized forms illegal. In all these cases,
there's not even the possibility of two interpretation, so there's really no
reason to mandate parentheses - other than one person's view on "good style".
(OK, so that person is Guido, which helps :-)

In summary, I can see no way of clearly explaining why certain cases of
unparenthesized if-expressions should be syntax errors. Unless there is such a
clear-cut, concise, explanation, I don't believe the syntax should be in error.
In my view, there should be 2 relevant rules:

1. "if" as the first token in a statement is *always* statement-if.
2. expression-if has defined precedence/binding rules which disambiguate
   all other cases.

If the rules in (2) are non-obvious, so be it. People *should* parenthesise
non-obvious cases. Such cases already exist.

Of course, there is an overriding fact - if the parser technology isn't up to
handling the 2 rules above, then that's fine. But in that case, *define* exactly
which constructs can't be parsed - and mandate that they are illegal. And point
out that parenthesizing removes the unparsability. [But it's the definition
that's important - most people don't *really* have an intuition of the limits of
recursive descent parsers...]

This has gone on too long - I hope I've made my point without labouring it to
death...

Paul.