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

[Nick Coghlan]

On 13 February 2014 20:22, spir <denis.spir at gmail.com> wrote:
> 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.

For your footnote 3:
http://python-history.blogspot.com.au/2011/07/karin-dewar-indentation-and-colon.html
:)

There may also be more in the papers about ABC:
http://homepages.cwi.nl/~steven/abc/publications.html (I skimmed the
"Issues in the Design of a Beginners' Programming Language" one, which
has some interesting parts about the indentation based syntax, but
doesn't really discuss the value of the colons that introduce a new
suite - I do personally like them though, as they provide a clear
distinction between statement headers and multi-line expressions,
especially when the header *includes* a multi-line expression)

> 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.

As far as I am aware, the =/== annotation is just an artefact of
Python's C heritage, rather than being based on anything more
profound.

> Why is it instead not obvious in Python [6]?

I don't know if Guido actually designed it this way, but if you
evaluate Python's original syntax as "simple statements are based on
C, compound statements are based on ABC", a lot of things make more
sense (and then the rest of the language evolved from there). So if
someone comes to Python having learned a language like C, C++ or Java
first, then it is only the ABC inspired bits (especially the
indentation based suites) that will puzzle them. If a new user learns
Python as their first programming language, then it all seems
arbitrary anyway, so they have no reason to expect anything different.

It requires expectations calibrated in a different environment
(perhaps including formal mathematics?) to make the C-style =/== model
seem particularly strange. Mathematicians may also be puzzled by the
use of "j" for complex numbers (although electrical engineers will
find that notation entirely familiar).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia