PEP 308: Alternative conditional operator forms

[Robin Munn]

Erik Max Francis <max at alcyone.com> wrote:
> Robin Munn wrote:
> 
>> Almost, but not *quite*, what I wanted to suggest. I propose:
>> 
>>     (x if C else y)   # Parentheses are *required*
>> 
>> This is identical to the format proposed in PEP 308 with the exception
>> that parentheses are required around the ternary expression.
> 
> The immediate reaction to this is that it doesn't seem fair in cases
> like:
> 
> 	f((x if C else y))
> 
> (without the doubled parentheses, it would be illegal).  If you want to
> special-case that one, then the grammar gets more complicated and
> eventually you start wondering why the parentheses should be required
> anyway.
> 
> Use parentheses for clarity, sure.  _Require_ them, I don't see.

And if parentheses aren't required, then that might be the one case
where I would consider leaving them out. Nevertheless, I still think
required parentheses are a good idea. I don't see much significant
difference between:

    f((x if C else y))

and:

    f([x for x in L])

List comprehensions are required to be enclosed by punctuation pairs,
even though it would be possible to parse them without those enclosing
brackets (the presence of "for" after an expression being what would
trigger the parser that this is a list comprehension). I wasn't reading
python-dev at the time when list comprehension syntax was being
discussed, but I can't imagine too many people wanting to omit the
brackets:

     x for x in L     <-- a (hypothetical) bracketless list comprehension
    [x for x in L]    <-- same thing with the brackets

The second one scans much better, IMHO. My eye can take in the
bracket-enclosed section as a single unit, recognize it as a list
comprehension, and parse it. Whereas the first format makes me do a
double-take and needs two slow passes to scan. First pass: "OK, the
value is x, wait a minute, there's a for. That's a list comp. OK, find
the end of the list comp..." Then back to the beginning for a second
pass to actually read meaning. If we require parentheses around ternary
expressions, I think it will have a similar effect:

     x if C else y
    (x if C else y)

Again, I think the second one just scans better.

OTOH, I'm not entirely convinced myself that it's necessary to require
the parentheses. Good style will demand that they be there, yes. And
I'll strongly recommend them to newbies who ask for help with their code
six months down the line. ("Strongly recommend" here means: "By the way,
that ternary expression really needs parentheses around it. It's the
accepted coding standard, and anything else looks desperately ugly.")
But I'm not certain that this is a case where we really need the parser
to enforce good style. Maybe we should take the "we're all adults here"
approach and let people leave off the parentheses as they see fit, while
still recommending (strongly) that parentheses be placed around a
ternary expression unless you have a darn good reason to do otherwise.

Look at that. I've managed to argue so convincingly against my own
position that I'm now -0 on my own idea. :-)

-- 
Robin Munn <rmunn at pobox.com>
http://www.rmunn.com/
PGP key ID: 0x6AFB6838    50FF 2478 CFFB 081A 8338  54F7 845D ACFD 6AFB 6838