AN INDICTMENT OF THE PYTHON PROGRAMMING LANGUAGE

Bruce David Wilner, CCP, CISSP
February 2001

It has recently become stylish to jump on the Python bandwagon. Revolutionary, some say; spellbinding, others add.

Hogwash.

I have seen languages come and I have seen languages go. I have personally written compilers, interpreters, translators, instrumentation preprocessors, etc., for ten or so. Python is probably the weakest addition to computer science in quite some time; it is arguably a giant step backward.

Let’s look at just a few reasons for my searing indictment:

• Python provides no apparatus—other than indentation—to delimit the scope of a control flow construct (loop, conditional branch, etc.). No artifacts such as BEGIN-END, DO-DONE, or { } are to be seen. This makes the language very handy for those who are whipping up quick scripts at an interactive terminal session and who are too lazy to type braces or who—after many years of programming—still don’t know where to find the braces on the keyboard. It makes the language brutally poor for those who are writing lengthy, formal programs that are to last for some time. It is a very undisciplined programmer indeed who would rather rely upon error-prone white space placement than upon precise delimitation of ranges by actual tokens.

• Indeed, Python now has the dubious distinction of being the first language since FORTRAN 66 and SNOBOL to assign semantic significance to white space (other than to separate otherwise adjacent lexemes). But it isn’t made clear how the interpreter decides what is more deeply indented than what. For example, is fifteen spaces more or less of an indentation than two tab stops? Recall that, on UNIX systems, the tty driver traditionally maps a tab stop into a maximum of eight spaces on output. Behold, we now find a language parser getting mixed up with terminal line discipline issues! The fact that white space is significant in certain contexts but not in others makes lexical analysis of the language rather challenging when using standard, regular expression based tools such as lex.

• I was shocked when first introduced to Python to discover that, in a putatively object-oriented language, there was no means to determine to what class an object belongs based upon its handle. Surely this oversight has since been compensated for, but such shocking omissions from the design of an OO language are inexcusable, and their having rapidly been patched a posteriori does not fill me with confidence.

• Almost incredibly, Python does not support declarations of variables: variables merely spring into being when they are first referenced. Much as was the case with the omission of scope-delimiting tokens, this oversight panders to the lazy typist while, in fact, constituting a gross error: failure to rigidly declare variables reintroduces a fresh source of uninitialized variable bugs—bugs that will vex the Python programmer though they wouldn’t stump a sophomore had he a more professional language to use.

• The author of Python has the nerve to trumpet the amazing flexibility of its data structures. I hate to burst his bubble, but he doesn’t offer anything that LISP didn’t offer forty years ago. The only difference is a minor dose of “syntactic sugar”: he provides certain shortcuts so that one need not reinvent the wheel—though a property list is a property list is a property list is an S-expression. The author’s continuation down his self-congratulatory path—where he compares his language favorably to Perl—is a disgrace. Perl astonishes me with its power and convenience every time I use it. (Admittedly, Perl’s failure to provide a straightforward syntax for defining class members and identifying them in the traditional aggregate-selector fashion is troublesome, but Python certainly has done no better.)

• Some of the syntactic oddities of Python are disturbing. For example, the fact that ( ) delimits tuples as well as expressions leads to the need to write ( x , ) to define a tuple that consists solely of x. With a bit more thought, something more professional could have been conceived.

This last one reminds me of a citation from an early C reference manual: “The syntax of initializers has changed: previously, the equals sign … was not present … The change was made because the initialization int f(1+2) resembles a function declaration closely enough to confuse the compilers.” Amusing, indeed—but this was excusable when it was penned 23 years ago. Python is only two years old.

• Like every other Johnny-come-lately, Python has attracted a fresh crop of parochial proponents who believe that anyone who disagrees with their paraprofessional fervor is somehow missing the boat, yea, a latter-day Luddite who would rather hide in the shadows than emerge into the Pythonic light (which I find rather more pythogenic).