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.