Py3K idea: why not drop the colon?

[Ron Adam]

Michael Hobbs wrote:
> Ron Adam wrote:
>> skip at pobox.com wrote:
>>   
>>>     >>>>> 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.
>>>
>>>     Ron> I wasn't that specific and it was related to Michael's suggestion
>>>     Ron> the colon wasn't needed. If the need for '\' was dropped in
>>>     Ron> multi-line block headers, then the colon would be required for an
>>>     Ron> obvious reason.
>>>
>>> But \ is used to continue all sorts of statements/expressions, e.g.:
>>>
>>>     x = a + \
>>>           b
>>>
>>> not just conditionals.
>>>
>>> Skip
>>>     
>> Of course, and your point is?
>>
>> How about if it be ok to continue to use '\' in headers, but it also be ok to 
>> not to?  That would be the backward compatible way to change it.
>>
>> This doesn't answer the question I was asking, are there any situation where it 
>> would cause problems?  And if so, that reason would be a good and explicit 
>> reason for not making such a change
> 
> To be clear, this is the actual thrust of my argument. It seems 
> redundant to have *both* line continuations and colons in compound 
> statements. I've been arguing for the removal of colons, though to be 
> honest, I'd be content with the opposite approach as well.
> 
> - Mike

Well, maybe you should consider working on that instead.  I think you will get 
much less resistance.


Consider the following points:

* There are not (that I know of) any true multiple line block headers in python 
but only long block headers with continued lines.

* It's probably more beneficial to simplify the more complex cases of multiple 
continued lines, than it is to simplify the already simple cases of non 
continued block headers.

* The block header can be identified in all cases by the initiating keyword and 
the terminating colon. (colons in lambda and dicts need to be identified first)

* The block header can not always be clearly identified strictly based on 
indenting as indenting in a block header spanning several lines is completely 
optional and may vary quite a bit depending on the programmers preferences.

* Line continuations are *already* currently optional in other situations.

 >>> a = (1,
... 1,
... 3,
... 4,
... 5)
 >>> a
(1, 1, 3, 4, 5)

 >>> b = (6, \
... 7, \
... 8, \
... 9)
 >>> b
(6, 7, 8, 9)


* Making line continuations optional requires no changes to the existing library.

* Removing colons would require changing block headers for all existing programs 
and pythons library unless you made the ending colon optional.  But that 
probably would create more confusion and hurt readability more than it improves it.


So giving these points, and any others you can think of, which do you suppose 
has a better chance of being implemented?

It also needs to be pointed out that the line continuations are a strong visual 
indication that a line is continued and not just a aid to the compiler.  So 
there will be resistance to changing that also.  (Over and above the general 
resistance to change most people have.)

Cheers,
    Ron