Py3K idea: why not drop the colon?

[Ron Adam]

Georg Brandl wrote:
> Ron Adam wrote:
>> Georg Brandl wrote:
>>> Ron Adam wrote:
>>>> Michael Hobbs wrote:
>>>>
>>>>> The same problem that is solved by not having to type parens around the 
>>>>> 'if' conditional, a la C and its derivatives. That is, it's unnecessary 
>>>>> typing to no good advantage, IMHO. I was coding in Ruby for several 
>>>>> months and got very comfortable with just typing the if conditional and 
>>>>> hitting return, without any extra syntax. When I came back to Python, I 
>>>>> found that I felt annoyed every time I typed the colon, since it 
>>>>> obviously isn't required. The FAQ says that the colon increases 
>>>>> readability, but I'm skeptical. The indentation seems to provide more 
>>>>> than enough of a visual clue as to where the if conditional ends.
>>>> I'm not sure why '\'s are required to do multi-line before the colon.
>>> Special cases aren't special enough to break the rules.
>>>
>>> Georg
>> A bit of a circular answer.
>>
>>      Why the rule? -> So not to break the rule?
> 
> You proposed to allow leaving off line continuation '\' only in the
> "if", "for" and "while" headers. This is a special case in my eyes.

I wasn't that specific and it was related to Michael's suggestion the colon 
wasn't needed. If the need for '\' was dropped in multi-line block headers, then 
the colon would be required for an obvious reason.

If the requirement for line continuations was omitted for "any" block header 
starting with a python keyword and ending with a colon, would it still be a 
special case?  It would be a bit less explicit.  Are there situations where you 
would want to explicitly limit a block header to just a single line because of 
some negative consequence?

I'm asking more for just plain curiosity, and not suggesting this actually be 
changed.  In practice I don't think its enough of a issue to warrant changing in 
python 2.x.  Although it just may (coin toss here) be beneficial for python 3k 
if extended annotations are implemented.

    Ron


>> I would guess this probably is more applicable in this case.
>>
>>      Explicit is better than implicit.
> 
> Of course, this always applies :)
> 
> Georg