PEP 308: Alternative conditional operator forms
mis6 at pitt.edu
Wed Feb 12 17:32:43 CET 2003
Evan Simpson <evan at 4-am.com> wrote in message news:<mailman.1044997847.31748.python-list at python.org>...
> Michele Simionato wrote:
> > As I said in some other thread, I want a clear distinction between the
> > "if" statement and the conditional expression. They cannot be distinguished
> > by a parenthesis only:
> "Cannot" in what sense? The grammar can handle it.
"Cannot" in the sense "such a confusion (for the reader, not for the
cannot be allowed in Python which is intended to be a language easy to
> > if C: print x
> > else: print y
> > is correct whereas
> > (if C: print x
> > else: print y)
> > would be a syntax error!
> Properly so. Why do you consider this to be a problem?
The problem is not with this specific example, but with the concept
that statements can be magically transformed in expressions with a
> > And what is this with parens that has to be there? This is so
> > inconsistent with how parens are used normally in Python.
> Function calls and defs require parens, tuple parens are optional, class
> bases require parens. Parens can also group expressions. Where is the
> consistency that is being violated, and what cost do you imagine that
> breaking it would impose?
Grouping expressions is not the same that converting statement to
expressions. Let me give an example:
is wrong now since a=b is a statement. It would be inconsistent that
in the "if"
case parens convert statements in expressions and not in other cases,
x=(for i in 1,2,3: i)
people would ask this to return the last computed value (I think Ruby
has something similar).
> > Moreover, I hate to call a function with
> > f((if C: x else: y))
> Do you also hate "f((x,))" to pass a one-tuple to a function?
Not because the fact that tuple are denoted by parens has been decided
from the beginning more that 10 years ago and there is no possibility
of error. Besides, tuple are expressions, not statements, I have
against parens in expressions.
> > and I hate the next unavoidable step
> > (try: X except: Y)
> "Unavoidable"? You've lost me.
If there is a precedent in the topic of converting statement to
how to stop people asking for other conversions?
> > Why to go over all this trouble when we have
> > C then x else y
> > without parenthesis, colons, if and with "then" not a keyword ?
> This isn't too bad, if it can be made to work. Having a magical
> non-keyword in the middle of an expression is hardly consistent with the
> rest of Python, though. Between that and chaining, we can construct:
> print now or then then then then then else now else "never"
Who is going to use "then" as a variable name ?? I checked that in
the full Python library (60,000+ lines) "then" is *never* used as
as an identifier. He could well be made a reserved keyword, if you
prefer so. I think the harm of having a "then" keyword is much
*much* smaller than the harm of having statement->expression
> In the spirit of your first objection above, we also have:
> C then print x else print y
> Evan @ 4-am
Nick Vargish already answered to that.
More information about the Python-list