End of Life (EOL) for Python 2.7 is coming. Are you ready?

 

End of Life (EOL) for Python 2.7 is coming. Are you ready?

We all knew it was coming. Back in 2014 when Guido van Rossum, Python’s creator and principal author, made the announcement, January 1, 2020 seemed pretty far away. Now we’re less than a year out from Python 2.7’s sunset, after which there’ll be absolutely no more support from the core Python team.Many utilized projects pledge to drop Python 2 support in or before 2020. (Here are all the currently Participating Projects.)

Now what?

The big issue: Python 3 is NOT backwards-compatible.  

Generally, that’s a good thing. Python 3 rectifies some fundamental design flaws and redundancies in the language, and that should lead to more simple and elegant code. But it also means that Python 2.x code isn’t automatically compatible with Python 3.

How and when to make the jump Just because 2.7 isn’t going to be maintained past 2020 doesn’t mean your applications or libraries suddenly stop working. If your project is stable and reliable and doesn’t have any security concerns, why fix what isn’t broken? Anaconda makes it easy to maintain your Python 2.7 environment so you can continue to run that software in the future. You can even have multiple projects in both P2 and P3 and manage them easily in different .conda environments.

Reasons to migrate:

  • You’re building a new project from scratch.
  • Your legacy project relies heavily on features that are different in Python 3
    • For example, Python 3 changes how strings are handled, making Unicode strings the default. This provides better support for accented characters, foreign languages, etc. If your application depends on robust handling of international characters, you really need to think seriously about going Python 3 only. It will be a lot harder to maintain code that works on both versions.
  • Your project relies on popular packages like Scikit-learn that have announced plans to drop Python 2 support.
  • You’re concerned about security vulnerabilities.

So how painful will your Python 3 migration be?

It doesn’t have to be that bad! The most popular libraries have already migrated. If you have a large codebase to migrate, survey your code for the key language differences between P2 and 3. That will help you understand the complexities you’ll be facing. Six provides utility functions for smoothing over the differences between Python 2 and 3 — and they have a handy compatibility library to help you understand the differences.

If you are currently developing code that needs to run in both Python 2 and Python 3, you should be using: “`from __future__  import print_function, absolute_import, division“`

This forces you to write code that’s Python 3 friendly, at least with respect to the `print`, `import`, and division statements. The sooner you start this practice in all of your code, the easier it will be later when you have to support Python 3 more deliberately.

We’re here to help.

If you’ve got questions about code differences, using .conda to maintain your 2.7 instance, or anything else related to Python 3 migration, feel free to reach out.


You May Also Like

Data Science Blog
Anaconda Distribution 2018.12 Released
We are changing versioning in Anaconda Distribution from a major/minor version scheme to a year.month scheme. We made this change to differentiate between the open source Anac...
Read More
Data Science Blog
Anaconda Distribution 5.2 Released
We’re excited to announce the release of Anaconda Distribution 5.2! With over 6 million users, Anaconda Distribution is the world’s most popular and easiest way to do Pyth...
Read More
Data Science Blog
Self-Service Open Data Science: Custom Anaconda Management Packs for Hortonworks HDP and Apache Ambari
As part of our partnership with Hortonworks, we’re excited to announce a new self-service feature of the Anaconda platform that can be used to generate custom Anaconda manag...
Read More