[Python-ideas] Making colons optional? Syntactic alternative.

spir denis.spir at free.fr
Thu Feb 5 13:26:02 CET 2009

Le Wed, 4 Feb 2009 23:35:30 -0330,
Riobard Zhan <yaogzhan at gmail.com> a écrit :

> Hi everybody,
> I'm proposing to make colons optional.

I 99% agree with that. But 100% sure this will never happen. No chance at all, imo... Still, it may be worth exchanging some thoughts on the topic as an opprtunity to take some distance, and watch python common traits with an outer look (correct?).

Block starts already are indicated, to humans as well as to the machine, by instruction type and indentation. Parsing for validity check or for editor smart indentation may rely on instruction 'type':

if last_instruction.type in block_headline_types: <whatever>

I personly do not find that expression's semantics more complicated than e.g.:

if last_instruction.text.endswith(':'): <whatever>

The first one has the additional advantage to prevent the common error of editors indenting after comments that happen to end with ":" ;-) Which by the way shows that relying on ':' is an wrong algorithm; as well as the fact that we get an error when forgetting ':' shows that python parsers actually rely on more information, namely instruction type.
Smart unindent in editors is already done that way, by identifying instructions like 'return' that very probably end a block and thus are followed by unindentation:

if last_instruction.type in probable_unindent_types: do_unindent

On the other hand, at the human semantic level, the presence of a ':' nicely introduces a block. One could object that this fact is basically western culture centered (like e.g. '#' meaning number is, as far as I know, purely english), but this is True for all common programming conventions. Computer science and technics is a product of western culture, anyway. People from other cultures have to get familiar with much more than arbitrary meaning of signs, before having a chance to explore computer programming.

A kind of meaning conflict nevertheless exists even in python itself: a ':' sign even more nicely carries a sense of binding, or link. Python uses this common world semantics in dict litteral key:value pairs.

Starting from this point, and looking for clarity and consistency, my wished syntactic revolution ;-) reads as follows:
* Get rid of ':' at end of headlines.
* Allow only single-instruction blocks (suites) for one-liners: "if cond; do_that". Or maybe no separator at all is necessary here for unambiguous parsing? Or replace ':' or ';' by 'then'. This would also allow if...then...else one-liners. Alternatively, make newline+indent compulsery. This is anyway often recommended in style guidelines.
* Extend name binding format "name:value" to assignments. That is, write "a:1" instead of "a=1. This may avoid tons of misunderstandings (imo, '=' for assignment is a semantic plague, a major error/fault, a pedagogic calamity).
* Which lets the "=" sign free for better use: use "=" for the semantics of equality, like in math and common interpretation learnt from school.
* Perhaps: use "==" for identity, instead of "is".

Again, this is not intended as a proposal for python, not even a hope ;-) Just a reflexion on alternative syntactic ruleset. I would enjoy comments & critics about that.


PS: I will take the opportunity to propose a thread on the topic of "binding vs rebinding".

la vida e estranya

More information about the Python-ideas mailing list