[Python-Dev] Python 2.x and 3.x use survey, 2014 edition (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Dec 13 15:48:51 CET 2014

On 13 December 2014 at 16:28, Chris Angelico <rosuav at gmail.com> wrote:

On Sat, Dec 13, 2014 at 5:13 PM, Donald Stufft <donald at stufft.io> wrote:

First of all, it's essentially the route that Python itself took and the side effects of that is essentially what is making things less-fun for me to write Python. Doing the same to the users of the things I write would make me feel bad that I was forcing them to either do all the work to port their stuff (and any dependencies) just so they can use a newer version of my library. Ultimately, those programs WILL have to be migrated, or they will have to remain on an unsupported system. You have the choice of either continuing to do what you find un-fun (cross-compatibility code) until 2020 and maybe beyond, or stopping support for 2.7 sooner than that. All you're doing is changing when the inevitable migration happens.

One of the biggest blockers has been the lack of ready access to Python 3 on RHEL & CentOS (just as a lot of folks waited until RHEL 7 and CentOS 7 were out before they started dropping Python 2.6 support). It's perfectly sensible for folks in that ecosystem to wait for the appropriate tools to be provided at the platform layer to make it easier for them to switch, but that unfortunately has consequences for upstream library and framework developers who have to continue to support those users.

The initial release of Software Collections (softwarecollections.org and the associated Red Hat downstream product) was the first step in providing easier access to Python 3 within the RHEL/CentOS ecosystem (as far back as RHEL 6 and CentOS 6), and that approach is still our long term preference for getting user applications out of the system Python (so upstream isn't stuck supporting legacy Python versions for years just because Red Hat is still supporting them for the base RHEL platform). Unfortunately, the usage model for software collections is sufficiently different from running directly in the system Python that a lot of folks currently still prefer to stick with the system version (and that's the case even for the much lower barrier of using the Python 2.7 SCL instead of the system 2.6 installation on RHEL 6).

Containerisation is another technology that aims to make it easier to run end user applications and services under newer language runtimes without interfering with the system Python installation. As with software collections, though, the environments that are reluctant to upgrade to newer versions of Python also tend to be reluctant to upgrade to newer deployment technologies, so it will take time for the full impact of the shift to containerisation to make itself felt.

Finally, in addition to the existing work on getting Fedora 22 (due mid next year) to only ship Python 3 on the LiveCD and other similarly minimalist installations, Slavek (the lead Python maintainer for Fedora & RHEL) is now also actively working on getting Python 3 into EPEL 7: https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3

Between the work that is being done to migrate the platform layer in the Fedora/RHEL/CentOS ecosystem, the work by Brett Cannon and others to improve the tooling around lower risk Python 3 migrations, the inclusion of pip in Python 2.7 to improve the availability of migration tools and backported modules, and the return of printf-style binary interpolation support in Python 3.5, several of the concrete challenges that make migration harder than it needs to be are being addressed.

Regards, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list