Py3K idea: why not drop the colon?

[Michael Hobbs]

Steven D'Aprano wrote:
> On Fri, 10 Nov 2006 15:18:55 -0600, Michael Hobbs wrote:
>
>   
>> Ron Adam wrote:
>>     
>>> It is also an outline form that frequently used in written languages.  Something 
>>> python tries to do, is to be readable as if it were written in plain language 
>>> where it is practical to do so.  So the colon/outline form makes a certain sense 
>>> in that case as well.
>>>   
>>>       
>> That is perhaps the most convincing argument that I've heard so far. 
>> Indeed, I often find myself writing out colons when writing pseudo-code 
>> out on paper. The reason, however, is usually because my indents don't 
>> quite line up as perfectly on paper as they do in an editor. The colons 
>> provide a form of backup separation for when my columns start to get 
>> sloppy. (Natural language is actually filled with such redundancies in 
>> order to compensate for sloppy handwriting.)
>>     
>
> Er, natural language pre-dates handwriting by many tens or hundreds of
> thousands of years. The redundancy of natural language has many reasons,
> but compensating for sloppy handwriting is not one of them.  
I was using the term "natural language" in a wider sense, as in spoken 
languages, unspoken languages (sign languages), and writing systems. As 
far redundancies in writing systems go, it has been estimated that there 
is ~50% redundancy in the characters alone. That is, you can usually 
determine what a character is even when half of its strokes are removed. 
That's not even considering other redundancies such as using a phonetic 
alphabet vs. ideographs, or writing the vowels between consonants, which 
only started with the Greek alphabet.

>> This backup function 
>> obviously isn't needed when a computer is taking care of the layout.
>>     
>
> That word you use, "obviously", I don't think it means what you think it
> means. There's nothing obvious about your conclusion to me.
>
> while (this really long expression
>     (which extends over multiple lines
>     and contains many statements)
>     some of which (like this one) contain
>     nested bracketed terms such as (this
>     expression here) but like all good 
>     things) it eventually ends
>     and we can get to the business
>     of executing the while-block
>
> Compare that to the version with a colon:
>
> while (this really long expression
>     (which extends over multiple lines
>     and contains many statements)
>     some of which (like this one) contain
>     nested bracketed terms such as (this
>     expression here) but like all good 
>     things) it eventually ends:
>     and we can get to the business
>     of executing the while-block
>
>
> Arguably, the parser might not find the first version any more difficult
> than the second, but I know which one I'd rather read.  
I'd rather read neither. Both of them are obviously illegible. As the 
saying goes, you can write FORTRAN code in any language. That is, no 
language, no matter what its parsing rules, can prevent you from writing 
illegible code if you're determined to do so. To me, the second example 
is no more legible simply because it contains a colon somewhere. Proper 
style would dictate that you make some form of obvious break when 
writing a multi-line conditional, no matter which language you're using. 
Some possibilities:

while (this really long expression
    (which extends over multiple lines
    and contains many statements)
    some of which (like this one) contain
    nested bracketed terms such as (this
    expression here) but like all good 
    things) it eventually ends:

    and we can get to the business
    of executing the while-block


or

while (this really long expression
    (which extends over multiple lines
    and contains many statements)
    some of which (like this one) contain
    nested bracketed terms such as (this
    expression here) but like all good 
    things) it eventually ends:
        and we can get to the business
        of executing the while-block


or

while (this really long expression
    (which extends over multiple lines
    and contains many statements)
    some of which (like this one) contain
    nested bracketed terms such as (this
    expression here) but like all good 
    things) it eventually ends:
    #### BODY ####
    and we can get to the business
    of executing the while-block


>> My final argument against the colons is to simply try programming in 
>> Ruby for a while and then come back to Python. I think you'll find that 
>> programming without the colons just simply feels more "natural".
>>     
>
> And maybe you're even correct. But one major reason of using the colon is
> to make it easier for _inexperienced_ programmers. Your suggestion that
> programming in Ruby for a while should be a prerequisite for making Python
> easy to read is an interesting one, but not one that many people will
> agree with. *wink*  
Is Python a cult, where it's considered dangerous to experience the 
outside world out of fear that it may corrupt your mind and make you 
question all sorts of long-standing edicts?

If you're concerned about coddling inexperienced programmers, maybe you 
should join Java cult. I hear that it is much more "safe" ;-)

- Mike