Python 2 Vs Python 3, Thank God that’s not Us!

Or is it…?

Python Splits in Two
In July 2010 Python 2.7 was released. It was the last version of the Python language to be released on the 2.X code base. Guido van Rossum (Python’s original creator) had decided that that the language needed to by “cleaned up” and that he’d prefer to do it without being hamstrung by the issue of backward compatibility. From July 2010 2.7 would have a long support life, but there’d be no new development done on that codebase and all new development would be done on the 3.X branch.

Choosing the Right One for You
So as a user of Python that makes life easy, right? If you’re starting something new you’d use 3.X otherwise you’d use the legacy 2.X branch, right? Hmm, well not so fast. You see one of the big pluses for Python is that it is “batteries included”, meaning there is a lot – and I mean *a lot* of libraries out there that you can use to speed your development process, but they are all on the 2.X branch. How many are on the 3.X branch, well hardly any – although that is getting better with time.

As a developer using Python, the choice now becomes: if it’s a legacy app, use 2.X; if it’s a new app, and the library you need isn’t available on 3.X then use 2.X; if it’s a new app, and the library you need is available on 3.X then use 3.X. Let’s face it, that’s not a tough call to make, so there’s no big deal there.

Things are somewhat harder if you are a developer of a popular library. Now, in the long term you have to re-write your library to support 3.X, that’s obvious, as it’s going to be the future of the language, so you have no choice. The issue is when? When is the best time to do the re-write to get the most from the upside of the cost/benefit equation? Well, it turns out that’s a function of how many of your users are doing something with 3.X, but how do you know. Guess? Survey? Something else? Well those things all have drawbacks, if only there was a better way.

We Don’t Have That Issue in .Net
Lucky for us that we’re not Python devs, right? I mean that’s a tough call to make, good job the underlying foundation upon which our code is built doesn’t have a radical change like that often, or ever even. But wait a minute, it does!

Or do We?
Okay, I’m not saying that the next release of the .Net framework isn’t going to be backwards compatible and that it’ll break everything, like Python 3.X isn’t backward compatible with 2.X. What I am saying is that if you are a .Net developer, and you want to take advantage of some new feature released in the latest version of the .Net framework, then you have to know which of your customers have made the move. Also, you need to know how many will be affected if you drop support for a particular version.

Loupe for the Desktop to the Rescue!
So now you are in the same same boat as the Python devs. Well, not quite. Luckily, using Loupe, you do have an advantage. Using the “Analyse Sessions” functionality in Loupe Desktop we can use the a pivot grid to query Loupe for number of Sessions, using which .Net version, by month, filtered by application.By using this functionality, you can answer questions such as “what effect will it have on my customers if I drop support for X version.

So there you are, just one more way in which you are better off than poor Python developers.

Well that’s all for this post, until next time, happy coding!