Python: the Good and the Mostly Bad

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.

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.

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.

Change in Amateur Radio Call Sign — W9IYN

WPE9IYN Shortwave Certificate
WPE9IYN Shortwave Certificate

Back in “the day” Popular Electronics magazine offered certificates for what it called “Short-Wave Monitor Certificate of Registration”. In the 1960’s I wrote in and obtained such a certificate and was assigned “station identification sign” WPE9IYN.

Part of the “deal” was that Popular Electronics also worked with the FCC to reserve the id (without the “PE” in the middle) so that your assigned station identification sign could also become your amateur radio service call sign.

I had intended to work towards an amateur radio license – my uncle and cousin were Hams. I spent some time learning code, but never actually took the exam.

So, after I obtained my license in February, I checked if W9IYN was available, and sure enough, it was. So, I applied for, and obtained that call sign as a “vanity” call sign. So, my Amateur Radio Service call sign is now W9IYN.

After some 53 years, I am finally a licensed Amateur radio operator (“Ham”)

When I was in middle school, my buddy Ross introduced me to the world of electronics by lending me his Knight Kit “Ocean Hopper” regenerative radio. We also worked together building a flip-flop circuit provided to us by a “traveling roadshow” on computers when we were in 8th grade.

When I was in 9th grade – junior high at the time – I was fortunate to receive the requested Knight Kit “Star Roamer” as a Christmas gift – still have that radio today.

In 1967 I wrote into Popular Electronics magazine, which was offering “call signs” as a “Short-Wave Monitor Certificate of Registration” for non-licensed receive-only hobbyists. At the time, they also coordinated with the FCC to reserve those call signs. I still have my certificate, and will eventually post it on my site.

Fast forward to Feb, 1, 2020, when I took the Technical and General amateur radio exams administered by the Volunteer Examiners from the Four Lakes Amateur Radio Club, and passed both with perfect scores.

My call sign was originally KD9OVL. However, I also applied for an FCC “vanity” call sign – which is the same as the one issued by Popular Electronics in 1967 (without the “PE” portion, after the “W” prefix.). I’ll let you know how that turns out. 😉

UPDATE: As of 3/10/2020, my call sign is now W9IYN.

73 (Amateur Radio lingo for “Best Wishes”)

Hello world!

Welcome to my website, which I have just released in November, 2019. This is my Blog section – if you are looking for something else, then see the menu at the top of the page, or visit my home page.

My website used to be at webpages.charter.net/thecomputercollection . However Charter (now Spectrum) stopped supporting subscriber webpages, so I moved it to a linode system. Their prices are great, and support has been availability has been great as well.

The site has been restructured, although quite a few similarities exist between this site and my old one. One obvious difference is the sidebar over on the right hand side, and the existence of “posts” — a capability provided by WordPress (a link for which is at the bottom of the pages in the website).

You can visit this link to see what the old one looked like.