Migrate to Python 3!

Python logo

My day job has been keeping me busy, and I haven’t had a lot of spare time to work on projects or to even read (I’ve got quite the backlog of reading to catch up on – particularly New Scientist and The Economist which are staples for my information appetite!)

That said, I’ve been working on quite a few interesting things, particularly a major migration to Python 3. The clock’s ticking on Python 2 (EOL at the end of 2019), major packages like Pandas are dropping support for Python 2 at the end of 2018, and minor packages are doing so as well. You can either stay on EOL/unsupported packages indefinitely, or migrate to Python 3 and leave all that mess behind!

When migrating to Python 3, it helps to have a plan:

  • Select a target version – I strongly recommend going straight to Python 3.6 or later as 3.5 goes EOL only a few months after 2.7.
  • On some platforms you may need to build Python 3.6 (not difficult), or use one from your repository of choice (e.g., the Deadsnakes PPA for Ubuntu).
  • Whatever you do, do NOT blindly replace your system Python with 3.6! Install 3.6 as a /usr/local/bin package and use it from there.
  • To minimize downtime for an active project, make your existing code cross-compatible as much as possible. 2to3 is the main tool for simply upgrading code but for cross-version compatibility I prefer Python-Modernize, which extends 2to3 so as to leverage six to allow cross-version compatibility. The very latest updates in its github repo enhance its. capabilities. Furthermore, I have a pull request pending that fixes something that causes more problems than it solves.
  • If you’re using TeamCity, I’ve written a wrapper for Modernize called modernize-reporter that reports the update details for each file it sees as needing updating back to TeamCity. Much like a linter, this will ensure your updated code stays up to date during the transition period.
  • Perform testing in parallel with Python 3.6 to flush out any bugs.
  • Cut over to Python 3.6 in production.
  • Remove six and other compatibility fixes – you won’t need them now!

I’m fortunate to be able to spearhead this effort where I am, but organizational inertia can be the biggest impediment of all in other places. Staying on Python 2.7 even past EOL is certainly easier and cheaper as it  avoids the risk of any downtime or pain points or effort required for an upgrade process.

On the other hand, not upgrading means sliding into The Land of Unsupported Software and a security profile that will only get worse over time. That’s a dead-end, and in this era of cybersecurity and privacy concerns maintaining brittle code on a brittle foundation is bad for business.

So make a plan, make your case, and get moving to Python 3!

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.