Py3K idea: why not drop the colon?

Ron Adam rrr at
Fri Nov 10 21:57:04 CET 2006

Michael Hobbs wrote:
> Ron Adam wrote:
>> The faq also pointed out a technical reason for requiring the colon.  It makes 
>> the underlying parser much easier to write and maintain.  This shouldn't be 
>> taken to lightly in my opinion, because a simpler easer to maintain and more 
>> reliable python parser means development time can be spent improving the 
>> language in other areas instead of fixing parsing problems every time a new 
>> feature is added that might be used in a conditional expression.
> Not to be too picky about it, but the FAQ was referring to editor 
> parsers, not the parser used by Python itself. The Python parser could 
> easily change its grammar to make the colon optional.

Yes, hmm. I seem to remember (possibly falsely) of someone saying it did make 
pythons parser simpler. Oh well.  Making it easier for third party tools and 
parser to parse is still worth while in my opinion.

> I find the editor parsing excuse to be weak since most editors tend to 
> get hung up on Python code anyway, regardless of the colons. (Except for 
> the ones that are specifically written to support Python, or are 
> insanely programmable, like emacs.) In fact, I find that my editor 
> usually gets confused when it comes across colons in dictionary literals 
> or lambda expressions. If it just stuck to looking at the indentation, 
> instead of trying to play off syntax tricks, it would behave much better.

My editor (GVIM) has the most trouble with long triple quoted strings.  I could 
probably modify the script a bit and fix that though.  I've never run into 
problems with colons.

In another post on this thread you use an example of consistancy as a reason for 
not having the colon.  But maybe sometimes there can be too much consistency, 
like when you want to differentiate something because they have different 
contextual meaning.

    xxx xxx:
       yyy yyy
       yyy yyy

Here the colon indicates a difference or change in context.  A test vs a 
procedure, or a grouping vs attributes, etc.  I suppose you could also interpret 
it as meaning 'related to'.  In a way this is carried over to dictionaries where 
a key is related to it's value.  A range is related to the loop body,  a test is 
related to the if body, etc...

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.


More information about the Python-list mailing list