Python: the Good and the Mostly Bad

(Updated 5/31/2021 – another for the “bad” list – see below.)

Let me admit, right up front, that I have some biases against Python. I have been programming in C and its descendants since 1976, and have used Perl for more than two decades. In particular in the past I have regarded Python’s abandonment of the usual c-style { and } for blocks particularly irritating, along with the requisite indentation rules that go along with that, particularly eccentric and irritating.

You can add to that formal training in compiler design and construction dated back to the 1970’s, and extensive experience with many different machine language assemblers and a long litany of higher level languages including BASIC, FORTRAN, ALGOL, COBOL, PL/I, LISP, SNOBOL, UNIVAC PLUS, C, C++, C# Perl, Java, javascript, PHP and more. I am no stranger to trying new things.

So, as an experiment, when I needed to write some code to check out the logical integrity of my IBM 1410 SMS database, I decided to try it with Python, since I had already read some of the “Learning Python” book by Mark Lutz and David Ascher (pub. Oreilly). And since this was a one-off that would not require ongoing maintenance, it seemed an ideal time to give Python a try.

What I found did not disappoint – I do indeed really dislike Python with good reason. And here is why.

On the Good Side

Python does have some nice features.

  • It has several IDEs — but since I was already using Microsoft’s Visual Studio for my project, I used that for coding.
  • I found its error checking for things like unassigned variables and miss-matches when assigning to a list (tuple) of variables attractive.
  • The tracebacks it provides on errors are extremely useful.
  • Finally, because it is still relatively new and because it has a rich library to begin with, it doesn’t (yet) suffer from the same kind of “CPAN Hell” that I have encountered with Perl from time to time.
  • And, an update about that: In July 2021 I wanted to install some code developed in Python that needed adjunct libraries – and very specific versions of those, at that. It suggested isolating them in a Python “virtual environment” to avoid any potential version conflicts on those modules, however, at least with ActiveState Python, the venv module does not function correctly, complaining about missing executables venvlauncher.exe and venvwlauncher.exe. Instead, ActiveState has chosen to include a similar module “virtualenv” – and also provide a platform-native tool called the State tool. Thus, it seems we have already entered the portal to “PIP Hell”.

But…. that is about it. I found nothing else to recommend in Python.

On the Bad Side

The list on the bad side is much much longer. The pity is that if it were not for the obstinance of those in control of the language, ALL of these would be easy to fix. Most of these cost me measurable time over the course of five days I spent developing my 850 line script.

And here is another “bad” entry, from 5/31/2021 . I use a Python based application, “weewx” to monitor my weather instruments and post to the web pages on this site (and weather underground). Last week my weather station started having issues, and I decided to replace it. As part of that, I decided to upgrade where I could – my Linux OS was quite old, the weewx software was a couple of years old and the Python in use was 2.7. Well…. guess what. This older version of weewx will not run under Python 3 because they decided to remove the file() method, replacing it with open(). Would it really have been so very very horrible to keep the old method around for compatibility sake? Could you imagine doing that to “C” programmers, or any other reasonable language? No, of course not. Of course, I do plan on upgrading weewx, as well, but this kind of things makes for “coupled upgrades” where interdependencies force upgrades to multiple components of a system at the same time – and this is not a good thing. (So, another instances of “rendering old code inoperable” as mentioned below.

First lets tackle the whole braces vs. indentation thing from a pragmatic standpoint, rather than just a religious one. This list is long, so I’ll do it with bullet points:

  • It already has half the combination there: you have to introduce blocks with a colon (“:”) anyway.
  • Any modern IDE can parse and clean up indentation anyway. This causes me to discard the various arguments that the indentation is somehow better because of the discipline it enforces on programmers.
  • Then there is the entire tab vs. spaces thing. Within a given IDE it tends to not come up at all, but, if you move code to another IDE, or someone else uses different tab to space conventions, watch out!!
  • It is so easy to do, and so compatible with Python, that a front-end, “pythonb” exists to translate from brace style to indentation. So, Python “gods”, why not make it an option?
  • The indentation rules make a mess of ordinary token-based parsing. As a result, you cannot break just any expression after any token as one can do with most other languages. No, you have to put the expression in what would otherwise be redundant parentheses. This costs real programmer time.
  • This same issue tends to confuse IDEs when you do continuations. It also means that every time you introduce a new block, the IDE starts in error mode because you don’t yet have anything indented below it, which slows the IDE down. More wasted time.

Next up comments. Python has no multi-line comments. I suppose some IDE’s can do that automagically, but Visual Studio didn’t seem to have a way to do that (even though it can do so for C#). So instead, when I wanted to make major changes, but keep the old code around just in case I either had to do a source control system (git or svn) commit of code that was not yet syntactically correct (which I really don’t like to do), fudge temporary code in (which I really don’t like to do), or copy the code into some kind of file-backed clipboard or text file to hold for a while. More wasted time.

Rendering old code inoperable, particularly between version 2 and version 3. Now, many languages and environments have had this issue over the years, but usually only on the fringes of what programmers do, leaving most code from and older versions compatible with newer versions. But not Python 3. All your old Print statements fail, integer representations change, octal constants change, and on and on. Again, this costs real time, when someone has to convert. I ran into it when the examples from my Python 2.3 book failed. So not only does this affect old code, it affects all the old publications and tons of examples out on the Internet. You guessed it: more wasted time.

Python also abandons some common-sense standard object methods one sees in most other languages. For example, converting an integer to a string automatically, and/or not having basic object notation compatibility so that things like object.string() or object.toString() or object.len() or object.length() or string.toint() when it makes sense. Instead you have to use a “built in function” to do this sort of thing, which can really mess up beginners trying to understand objects because the primitive types don’t behave like objects. This is especially bewildering in a dynamically typed language.

Even a Python dictionary can provide its string representation, but not primitives. How very primitive.

And, while you are at it, why not provide an implicit string to integer conversion too, based on context, and trigger an exception (which Python is really good at) if it fails? In languages like C# where good error checking up front is paramount, it is understandable that you have to code for this. But not in a “scripting language” like Python.

The lack of built-in integer to string conversion is particularly annoying in dealing with databases — you have to be constantly aware of whether a column is integer or a string. Now, when writing “real” code that is going to be around for a long time, that is perfectly fine (well, almost), plus you have strong compile-time type checking to help out. But when trying to write a script in limited time, in a dynamically-typed language, it gets in the way and wastes time.

This affected me in a several ways:

  • It prevents useful auto-completions for these basic things. You have to lead with an arbitrary function name, instead of simply typing the object you want, hitting “.” and then picking the method you want. Time lost.
  • It introduces parentheses around things like str(string) and len(string) which also makes editing harder. More time lost.
  • You can reasonably code tupleVariable.count(), but not stringVariable.count() . The latter exists, but counts sub-strings, not symbols in the string.
  • It results in str() sprinkled all over the place to do basic integer to string conversion. (Fortunately, str(string object) works, otherwise I probably would have thrown in the towel when I first ran across this. )
  • I had to be really careful to be consistent with indexes into Python dictionaries (akin to Perl hashes), because dict[i] does not match dict[str(i)]

Single element tuples are problematic because the designers chose () to designate a tuple. So (“string”) is just the same as “string” whereas (“string1″,”string2”) is a tuple. But () is an exception, and creates an empty tuple.

When I was retrieving data from MySQL, if a row had only one column, I could not use “(variable) = cursor.fetchone()” for example. I had to use “variable = cursor.fetchone()[0]”. This may well actually be a bug in the MySQL library, but it was very confusing until I figured it out, and cost me time. (I just realized that maybe if I had used “(variable,) = cursor.fetchone()” it may have worked. )

Also, the result is also that a print(singleElementTuple) has a trailing comma where as a print of (twoElementTuple) does not. (really, to be consistent, the notation for a zero element tuple should be (,). Instead, that generates a syntax error. Its just inconsistent as heck.

And these were annoyances that I found after only maybe 10 hours of time.

Leave a Reply