>> 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>.
Tim> Guido can exempt himself from the PEP process if he feels like it.
Tim> If he does, I expect I'll be in the "retroactive PEP" business
Tim> again.
I'm sure he can, but that doesn't mean he ought to. <wink>
>> The parens function pretty much as "{...}" in C, Java, Perl, etc.
Tim> Sorry, I don't see the resemblance.
Well, the examples I saw looked like
x = (if (if e1 then e2 else e3) then e4 else e5)
Seems to me that those inner parens are there to separate the inner
conditional from the trailing parts of the outer conditional:
x = (
if (
if (
e1
then
e2
else
e3
)
then
e4
else
e5
)
Whether or not that's what they are in a language parser sense, they sure
look like it to the human eye.
>> 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.
Tim> I'm not concerned about 21 bad arguments versus 20 <wink>.
That 21st argument will be a little stronger than the other, because it will
go something like, "Why can't we have delimiters for block statements?
After all, we have them in conditional expressions." The reference, instead
of being to another language, will be to Python itself.
Skip
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