[Python-Dev] Python 2.x and 3.x use survey, 2014 edition

[Nick Coghlan]

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