I spent more than a decade and a half in a software engineering job where backwards compatibility is a must, all day, every day. It’s very disorienting for me to switch to a world where such a sacred commandment would be discarded as when Python 3 was launched with severe incompatibilities from Python 2.

As a novice to Python, I was not aware of the problems that Python developers tried to leave behind in the break and I’m also ignorant of the positives Python 3 offered as a benefit to balance the cost. All I saw was the aftermath of an incredibly disruptive change that, almost a decade after it started, is still far from complete.

Part of my motivation to learn Python is ROS, which is still on Python 2. This meant I’ll have to deal with the transition costs even though I’m new to the scene. This was not a happy introduction to the world.

Fortunately the lengthy transition also meant there’s been time for people to voice similar concerns and for the people behind Python to write up their explanation. There’s a fairly lengthy explanation on Python.org titled “Should I use Python 2 or Python 3 for my development activity?” which links to an even lengthier “Python 3 Q&A” that has evolved over the past five years.

After reading it all, I see their point. Especially the parts around Unicode support. I can see how changing behavior of a fundamental concept like strings in a language can’t be done without breaking compatibility, and I can understand why it is a required transition for the language to be successful in the rest of the world beyond the English-speaking communities.

I don’t have to be happy about it, but I can at least understand it, and that does help to make me a little less grumpy when I have to deal with the aftermath.

It’s somewhat embarrassing to admit my first impressions of Python came from programmer humor. The first one I can recall is xkcd #353. Another one that made an impression was the “If programming languages were essays” series.

The common thread is the tremendous library of tools available to python programmers just a “import” command away. I think the hard part of me getting up to speed in Python won’t be the syntax or the constructs, it’ll be getting to know what libraries are available. I foresee my biggest hurdle to Python productivity would be spending three hours writing something before it occurs to me to look for a library where someone has already done the work, find it, and finish the task in 15 seconds.

It makes sense that this ecosystem of libraries is a huge strength to Python and also an equally huge liability and a hindrance in transition to Python 3. By breaking backwards compatibility, Python 3 had to rebuild this ecosystem of libraries from scratch. It’s hard for people to find motivation to use the new Python 3 – with its limited set of ported libraries – when they could stay with the comfortable group of friends they already know in the Python 2 world.

To learn the ropes, there’s nothing like diving right in. I wanted to write a simple script to handle a task I had: enumerate video files in my collection and call FFmpeg to convert them from their old formats to the modern MPEG 4 Video format (h264 + AAC). Most of what I need to do for walking the directory tree comes from “import os” and “import os.path“. Calling FFmpeg turns out to be trivial after “import subprocess“. And the final icing on the cake: a library to parse command-line parameters using “import argparse“. Argparse even has a HOWTO tutorial to walk me through using it.

In less than an hour, this complete novice was able to build a decently robust Python script for video conversion.  Color me impressed.

Zipping through the Python 3 tutorial from the Python Foundation, some things stood out more than others. Coming from a background of work in C, C++, and C#, I found the following items interesting:

Strings

String handling is something every programming language has to deal with and a good way to feel how the language designers solve problems. C approaches bare metal and has historically proven to be error prone. C++ offers the choice of going with C or taking the performance overhead of string libraries in exchange for reduced headaches. C# reflects a more recent school of thinking where the programmer is prevented from shooting themselves and all their customers in their collective feet. Python is in the last bucket and I’m happy to see it.

A different ‘for’ loop

Python’s for loops always iterate over items of a sequence, and not based on an integer index like I’m used to from C and C++. It feels like foreach from C# but hopefully without the negative performance impact.

An ‘else’ block after a loop?

The ‘else’ block of a loop was a novel idea to me. I’ve never had this tool in my toolbox and my brain isn’t used to structuring code to take advantage of this mechanism, but I am optimistic I will find it useful.

Python classes

The Python designers took a very different path to implement classes than any other object-oriented language I’ve learned. The tutorial began with some background, a big wall of text that I originally thought I’d skip thinking it’d be repeating things I already knew. Now I’m glad I put in the effort to read it. Python classes look familiar at first glance, but after reading about the nuts and bolts, I know I’ll get into trouble if I had treated them the same way as C++ classes.

I expect I’ll still get into trouble, but now I’m optimistic I will understand why and be able to dig my way out.

I took the Codecademy Python class several months ago when I surveyed various technologies. It appears I didn’t write a short note about it which is too bad because I now want to look over what I thought at the time. In my vague memory, they wrote it for the absolute beginner and spend a lot of time teaching basic computer programming concepts. (Variables, flow control, etc.)

Python is again as a topic of interest for me. It is one of the primary languages for working with ROS and also in a lot of machine learning/AI fields. (OpenAI gym is Python, Google’s TensorFlow is primarily focused Python, etc.) I think I should try to gain proficiency in the language but I didn’t want to go through a beginner-focused class again.

To review Python from a different starting point, I started going through the Python Foundation’s own tutorial for Python 3.6. I quickly determined the target audience are people already familiar with programming in another language and want to get up to speed in Python, which perfect for me! It was quite useful for me when the authors described Python features in terms of how it is similar to or different from C++ features.

On the flip side, I was reminded why I was down on Python: the incompatible break between Python 2 and Python 3. They’re both fundamentally the same language but in real world usage they are now effectively two different languages. Python libraries written for Python 2 could not run unmodified on Python 3, and vice versa. So they will have different install instructions, etc. Over eight years after the initial release of Python 3 the entire ecosystem is still undergoing the pain of  this transition.

OpenAI and TensorFlow appears to support both Python 2 and 3, with separate setup and usage instructions. ROS has the official  ambition to move to Python 3 but is currently still stuck on Python 2 due to the existing base of Python libraries.

Despite the temptation to stick with Python 2 for ROS, I decided to jump into the Python 3 tutorial and I’ll deal with Python 2 weirdness as they come up later.