[Python-Dev] The end of 2.7

[Nick Coghlan]

On Sun, Apr 7, 2013 at 6:01 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> Or, if they have paid support from a vendor like Red Hat, hassle the vendor
> for a fix. Speaking of 2.3, as I understand it Red Hat still offer paid
> support for 2.3, which won't expire for a few more years, and security fixes
> only for some years beyond that.
>
> [By memory, which may not be entirely accurate.]

Correct, the system Python in RHEL 4 is 2.3 and that is still a
supported platform if you pay for the Extended Lifecycle Support
(until early next year you can still get extended support for RHEL
*3*, and I believe the system Python in that is 2.2). RHEL 5 ships
with 2.4 and RHEL 6 with 2.6 and those are both still in their regular
support period. The system Python version in the upcoming RHEL 7
release hasn't been formally announced yet, but it doesn't take a
genius to figure out what it is going to be when the system Python in
Fedora is currently still Python 2.7. I'll also note that regular
support for RHEL 6 doesn't end until 2020, and extended support in
2023, so even Python *2.6* should have commercial support available
for another decade, let alone 2.7.

These supported versions are also (or will also be) available for free
through CentOS, ScientificLinux and other Red Hat derivatives.

It actually isn't the bug fixes which I consider particularly
important in 2.7 - it's the build fixes (including the
cross-compilation support). As the IDLE team ramp up their efforts,
there may also be benefit in getting updated versions of IDLE into the
hands of beginners (remember, a huge amount of training is enterprise
focused, which isn't likely to switch to 3.x until after Red Hat does,
and that migration has barely started on the Fedora side - having the
installer and package management system written in Python means that
migration is likely to open up some fairly major cans of worms).

Python 2.7 is a mature, stable platform for software development.
Python 3.3 is *better* in most respects, but if you've already worked
around (or aren't affected by) the text model issues in 2.x, then most
of the cool features in 3.x are available as backported modules on
PyPI.

With the lifting of the language moratorium. 3.3 has taken us further
down the "carrot" path for migration (adding the more efficient
Unicode representation, the "yield from" notation, more memory
efficient objects, import system enhancements and the improved
exception hierarchy to the pre-existing carrot that is chained
exceptions).

3.4 will likely add even more carrots, as we take further advantage of
the cleaner code base that was gained in the 3.x migration.

I think it's quite reasonable for individual committers to decide how
much we want to worry about Python 2.7. I know I've fixed some bugs in
3.x and then left the issue open as still applicable to 2.7 (usually
because the bug affected some part of the code that changed in the
transition, so the backport isn't straightforward). I consider that a
reasonable thing for me, or any other committer, to do: leave issues
open as applicable to 2.7 rather than doing the backport immediately.
If someone else cares enough to backport it, great, otherwise the
issue is still there to indicate that the problem still exists in 2.7.

Regards,
Nick.

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