On Sun, Apr 7, 2013 at 6:01 PM, Steven D'Aprano <st...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
