Why Not Python ?

There once was an article in Linux Journal written by Eric Raymond, which describes why Eric started to use Python. For me, there are some strong reasons not to use Python, at least not for major tasks, As ‚Why Python‚ was written in English, I do my counterpart ‚Why not Python‚ in English as well.

I have been a programmer since 1983 and since that time I had to deal with a number of programming languages. It started all with RPG-II which was invented by IBM as a business-oriented programming language very much like Cobol (though having a very different format).

Over the years I learned C, C++, Perl, Assembler, Basic, SQL, CL, some common shell scripting languages and the like. They all have their own peculiarities and quirks, but all in all they usually present an evident grammar which doesn’t lead to inconsistent or even absurd syntactical constructions.

Python is praised all over the web for its simplicity and obviousness concerning the underlying syntax, and even the syntactical whitespace which -as a part of the Python programming language- is widely described as something useful which ‚you will soon not only accept but even appreciate‚ because ‚it makes programs much easier to read‚.

Neither the first was ever true for me, nor do I consider the ‚formatting‘ of a source code to be a sufficient reason for a particular grammar. Consider a student which had to design a programming language as a diploma work: If he had to explain his professor why he had chosen a particular grammar for a programming language, and he would answer: „because it looks nicer“. Do you think he would get a good grade?

For me, ‚syntactical whitespace‘ is a nightmare. And furthermore it is absolutely unnecessary and at the best a matter of personal taste – but never of a programming- languages grammar. Imagine a language, whose functionality depends on the width of your editor-tabs if blanks and tabs were used in mixed within a source file which you are about to read? And so much the worse, you cannot ’see‘ whitespace of different type, it’s all just ‚white‘.

The Python documentation doesn’t even blush at all to give the explicit advice ‚not to use blanks and tabs‘ in a source code alternately, as this can lead to ‚unpredictable results‚. But whitespace is nevertheless part of the language as a syntactical, and even worse: semantical (!) element. Wow, what a design!

Besides this: Whenever I find a source which -due to inconsistent indentation- doesn’t look ’nice‘, it’s my editor which helps out for that ‚problem‘: In emacs, I simply do an ‚indent-region‚ command, and thats it. So I do not need any language-designers care when it comes to the question whether and how I like a program to be formatted. For me, such care is much to close to typical socialistic paradigms: I don’t like technical babysitters which tell me that I have to organize my source-code in a way that they prefer.

It have been likely the same people which designed some other, grammatical intolerabilities.

Consider a task, which shall do something as long as a particular condition is true. The textual form of such a construction is approximately sth. like ‚while there are still records to read from a file, read the next record‚. This workflow shall undoubtedly end, when EOF has been reached. There is no meaningful ‚else‚ branch conceivable, but in Python this is part of the grammar:

while(not at EOF)

read record from file

process record

else

???

Even worse, such else branches can in Python exist for ‚for‘ loops. Common programming languages already imply the ‚else‘ by just closing the corresponding code-block, namely

for (x=1; x<10;++x) {

do something

}

which is semantically nothing other than

x=1

loop:

do something

x = x + 1

if (x < 10)

goto loop

else

goto endloop

endloop:

In fact, one can omit the ‚goto endloop‘ here, but it is to demonstrate what the implicit ‚else‘ part of a loop is. The Python documentation states, that the ‚else‘ branch of a loop is ‚executed once‚ after the loop has completed. Yes. This is the case in other languages as well, they use to continue their workflow after a loop which means that any single statement after the loop is executed in sequence, one by one, one at a time, once. As a ‚for‘ or a ‚while‘ loop does no express an explicit ‚if‘ clause, there is not only no need for an explicit ‚else‘ clause, it furthermore is mind-boggling and even worse: it is broken syntax.

But the most hefty reason for me not to prefer Python over other languages is that it simply lacks performance. It is in most of its parts much slower than Perl, and it is a several hundred times slower than C++, not to talk about C.

Whilst such performance issues are probably not significant for small helper-scripts, and very often not significant for GUI frontend-programming since the user-interaction is the most time-consuming part in such an application, these issues are in general an absolute no-go for other use-cases than these. One might think, that nowadays such performance questions are no longer an issue. But this is simply wrong: Servers as well as desktop systems nowadays are usually loaded with tons of services, each of which consuming resources which are not available infinitely, no matter which hardware one uses. And these services are getting more and more, each of which eating up ten or hundred times the memory, processor-time and other resources than would be necessary if they were written in an efficient language. So the resources in question have to be increased – thus establishing hardware configurations which could be much smaller in size, cost and – energy-consumption.

Yes, the name Python is derived from Monty Pythons Flying Circus. One should perhaps  think about the question, whether the Python inventors really had something serious in mind when they designed this thing. So if Python is just a tribute to a comedian-troupe, then my assessment of this language matches exactly my appreciation of Monty Python: I never liked them at all.

Comments are closed.