Py3K idea: why not drop the colon?

[Michael Hobbs]

Steve Holden wrote:
> Michael Hobbs wrote:
>   
>> Ben Finney wrote:
>>     
> [...]
>   
>>> A use case. What problem is being solved by introducing this
>>> inconsistency?
>>>   
>>>       
>> 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.
>>
>>     
> So you'd also like us to shorten the names of the builtins and the the 
> keywords? Why bother with "def" when we could just use "d", "class" when 
> we could just use "c"? Or *does* readability matter to some degree?
>
>   
Like I said in that paragraph, removing the colon wouldn't seem to 
degrade readability *that much*, if at all. Personally, even though I 
find typing the colon to be a small annoyance, that annoyance exceeds 
any improvement to readability that it might provide; especially 
considering that indentation sticks out like a big red sign saying the 
code block starts "HERE, HERE, HERE".

>> As far as using the FAQ as gospel, the FAQ also provides arguments for 
>> why there isn't a with statement or a switch statement. The with 
>> statement has already been implemented in 2.5 and there's a PEP to 
>> implement switch (3103).
>>
>>     
> But the "with" statement isn't the one that "with" was reserved for in 
> the FAQ, which is really talking about the same kind of "with" statement 
> that Visual Basic uses: an implied left operand for unary "." operations.
>
>   
Yeah, okay, I didn't read through the details of the PEP. I picked a bad 
example to illustrate a point that is still true. The FAQ also tries to 
argue that it's a Good Thing that join() is a string method, not a list 
method. It also tries to argue that there's a good reason that lists are 
different than tuples. I don't think it would surprising that many 
Python developers don't really buy those arguments either.

- Mike