Related link: http://www.amk.ca/quotations/python-quotes/
We will perhaps eventually be writing only small modules which are identified by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language.
–Donald E. Knuth, “Structured Programming with goto Statements”, Computing Surveys, Vol 6 No 4, Dec. 1974
I love to tell people how I discovered Python. I was just getting into Red Hat, back in late 1996 (Red Hat 4.0, if I remember correctly). I was using the printer set-up UI and it broke, leaving a traceback to the screen. I remember on a lark following the traceback to the source file, which was in a languae I hadn’t heard of. Reading the section of code around the reported failure, and after a bit of trial and error, I was able to fix the bug and that got the printer applet working again. I don’t remember the details, but I believe it was a misplaced variable assignment in one of the code branches.
I did not look at a single reference on Python during that incident. I was pretty much blown away at how clear the language was, and I’ve been a strong Python user and advocate ever since then. But this discusson is about indentation The funny thing is that I didn’t learn that Python required indentation until I later on read the Python tutorial, trying to get properly into the language. Even then, I don’t recall that, that detail caused me a moment’s pause.
When I was working on the printer GUI, through all my trial and error I always just naturaly followed the indentation that was in the code module. I was a C++ guy at the time (and just beginning to learn that things were deeply amiss with Java) and everywhere I’d ever worked, your code would be rejected upon review if you didn’t meet code standards, of which indentation was a prominent part. For this enforcement to come from the language rather than peer review seemed a natural progression.
I remember the Knuth Indentation Quote (KIQ) coming up in the Python community. There was some talk a few years ago in the Python Software Association of putting it on a T-shirt for sale (I don’t believe thre was ever such a T-shirt designed but one of the IPC T-shirts hadd the motto “Life’s better without braces”). I never really appeciated the quote because I always felt that I’d rather advocate Python based on serious considerations of expressiveness and flexibility rather than combating what I hold to be frivolities. And I didn’t really know the context of the KIQ.
Now Python has firmly entered the mainstream. There are still people who make an amazing amount of noise about a syntactic feature that enforces clarity. Over the years I’ve heard many criticisms of Python, many which have been very valid, and many of those which have since been addressed. This included poor Unicode support, lack of closures, tendency towards memory leaks and speed. I have never taken anyone seriously who held the indentation as a serious defect in Python, and so I might as well use the KIQ as the light-hearted tool it is. In future, rather than rolling my eyes the next time someone says “Ewww. Significant whitespace”, I’ll just smile and trot out the words of the greatest mind in the history of computer science (sorry, Turing and von Neumann fans).