[Skip]
> >> Is the thread in c.l.py on conditional expressions leading in the
> >> direction of actually getting added to the language, or wer Tim's
> >> experiments done just to show it's possible?
[Paul Svensson]
> Ick. Please don't tell me that's more than a bad joke ?
[Tim]
> Tim> We (PythonLabs) were wondering whether to reserve any more
> Tim> keywords for 2.2. "then" was a natural candidate, for this
> Tim> specific use. Guido and I have been playing with it. If
> Tim> it proves to be a low-hassle, low-impact change that works
> Tim> well, the intent is to get it in for 2.2b1 later this week.
> Tim> Doesn't look *likely* to me at this point, but don't know.
[Skip]
> Regardless whether or not you think this could make it into 2.2b1, I
> hope if you proceed it will get a PEP a reasonable amount of time
> before the CVS checkin... <0.1 wink>.
>
> It seems downright weird to me that the syntactic baggage necessary
> to write a conditional expression is greater the the baggage
> necessary to write an if statement (new "then" keyword, parens
> required for disambiguation). The parens function pretty much as
> "{...}" in C, Java, Perl, etc. It's a step away from
> indentation-based block structure and toward delimiter-based block
> structure. If you add it, I think it will be harder to justify the
> lack of delimiter-based block stucture at the statement level. It
> will just be one more argument in the arsenal of people whose
> knee-jerk reaction to Python's block structure is to whine about it.
I think you must be misunderstanding the proposal, which is to add
if <expr> then <expr> else <expr>
as an alternative to the expression syntax. Here's a preliminary
patch (which I won't apply until I have more confidence that this is
acceptable to the community):
http://sourceforge.net/tracker/index.php?func=detail&aid=471421&group_id=5470&atid=305470
The parens in this proposal (my version) act no different than any
other use of parentheses in Python expressions. Basically, you need
to add parentheses to disambiguate expressions:
- if otherwise the 'if' keyword would be the start of a statement
(because 'if' at the start of a statement starts an if *statement*,
and the parser can't look ahead for the 'then' keyword);
- if the conditional expression is to be combined with a unary or
binary operator.
Some examples where no parentheses are needed (note that a comma binds
less tight than a conditional expression -- same as for lambda):
x = if 1 then 2 else 3, y
f(if 1 then 2 else 3, y)
a[if 1 then 2 else 3, y]
`if 1 then 2 else 3`
lambda: if 1 then 2 else 3
Some examples where parentheses *are* required:
(if 1 then 2 else 3) + 4
a[(if i then 2 else 3) : 4]
In some situations I'm not sure what's right; The un-parenthesized
form looks weird although it's not neede to avoid ambiguity:
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'd be happy to discuss this more. I'm *not* happy with responses
like "is this a bad joke?". I don't understand how this could be an
argument in the arsenal of the anti-Python league.
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4