[Python-ideas] on colon ':', and some more

[spir]

Hello,

This is not a proposal for change, rather a few reflexions I guess were worth 
being shared here, because this is a list where design questions about Python 
are debated. If you don't care, just press 'del'.

I have always been puzzled by Python's usage of colons terminating block 
headlines. First, this does not match the overall noise-less design of the 
syntax; second, it compares weirdly with the absence of (required) semi-colons 
terminating instructions [1]. I stepped several times, in online articles, on 
vague evocations of "studies" supposed to "show" that this format is clearer to 
beginners, albeit each time without any reference to said studies [2]. Finally, 
I recently found what seems to be the actual story of ':' [3], telling that, 
according to _one_ non-programmer, colons should be added there to play the role 
of _introducing_ the following block, indented. This notion of _introduction_ 
endly clicked for me, making some sense.

 From a distinct perspective: another weird point is using '=' for assignment 
and '==' for equality [4]. In my view, the right assignment sign (rather: the 
sign to define a symbol, in general) is ':' precisely [5]. While thinking at 
syntax for a low-level language, I stepped on the special case of symbols which 
are labelled blocks (all targets of jumps/goto's, including procedures). In 
assembly and some other langs, they are usually written 'label:' or ':label:'. 
And indeed it is clear here that the label introduces the following block, with 
':' obviously playing this introductory role.

Why is it instead not obvious in Python [6]? Maybe the reason lies in the actual 
usage of colons, in fact in the actual headlines in python code. In assembly, 
one could have code looking like:
     jnz case-true
     ... (case false) ...
     case-true:
         ld rax result
         ...
Here the label is a kind of title line for the block. There is a similar usage 
in python:
     def average (numbers):
         sum = numbers.sum()
         return sum / len(numbers)
Again, here the headline is a kind of title. However, when the block is a 
control statement if/else, for, while, then the headline is rather an 
_articulation_ in the discourse:
     for n in numbers:
         print(n)
     while more:
         go_on()
     if cond:
         this()
     else
         that()

 From yet a third perspective: for a high-level language this time, which 
otherwise uses indented blocks like Python, I was searching for a nice syntax 
for single-line control blocks [7]. As in python's:
     for n in numbers: print(n)
     while cond: go_on()
     if cond: this()
     else: that()
I first thought at using 'do':
     for n in numbers do print(n)
     while cond do go_on()
     if cond do this()
     else do that()
     if cond do this() else do that()
which is very nice, I guess. [8] [9] Then, for whatever reason, came to my mind 
the following:
     for n in numbers, print(n)
     while cond, go_on()
     if cond, this()
     else, that()
     if cond, this() else, that()

Just using ',', a bare comma. [10] It seems to me that this usage of the comma 
matches its meaning in ordinary (written) discourse. And there is indeed a 
question of discourse articulation. Here, of logical articulation, precisely. 
Maybe this is why, finally, Python's usage of the colon does not meaningfully 
click as it should: because most of the time it's not a question of a title 
introducing a block, but of discourse articulation; where ',' would do a better 
job, maybe.

Note: I don't mean this post to introduce (sic!) endless violent discussions (as 
often, on such topics); and I won't reply if this happens. I wished to share a 
different view on the topic, for people who care about meaningful syntax.

d


[1] I think the parser should not an accept optional ';' at end of line. This 
alternative is never used, and, if it were, would only trouble novice 
programmers (What the heck does ';' mean? nothing...)

[2] Which always made me laugh, knowing how supposed studies in the fields of 
psychology or sociology usually are highly contestable; so what about 
programmers or CS professionals driving such studies?

[3] Someone will surely have a pointer ;-)

[4] Forgetting ':' and using '=' for equality are my favorite syntax errors in 
Python. I seem to still love them, still after long years of frequentation.

[5] Python uses it in dict notation, which is nice. But dict key->value links 
could use '->', while for symbol defs ':' or '↔' or '⟷' would be perfect. 
(Actually, the double head arrow is ideal, but unfortunately there is no such 
key on common keyboards.)

[6] Not obvious at all, for me, instead I had to be told about it, I mean to 
read about it. Maybe it is non-obvious for most people, since this argument does 
not seem to come up in discussions about ':'.

[7] The actual keywords are different, also the syntactic schema for procedure 
call, but I will use Python's syntax here in examples for readability.

[8] However, syntax highlighting for keywords would help, here.

[9] Not invent here: Lua uses 'do'; however also for multiline blocks, and only 
for loops, not for if/else.

[10] This is even better in the case of this lang project, where like in Lisp 
collection items are just separated by spaces: no commas. Thus, the comma has a 
clear and single role in syntax.