The future of Python 2 [LWN.net]

The future of Python 2

Posted Apr 25, 2013 12:31 UTC (Thu) by phred14 (guest, #60633)
Parent article: The future of Python 2

I work in industry, and the platform I'm given to work on is based on RedHat Enterprise 6.4. The available Python is 2.6.6, not even 2.7, and 3.x isn't even available as a try-it option.

At home I run Gentoo, and they have 2.7 and 3.2 both installed, though they're currently using 2.7 by default and are in the long process of making sure 3.x is fully enabled.

In this environment, while I may be intellectually curious about 3.x, the bread on my table depends on 2.6, and 3.x qualifies as a "distraction". About the time 3.x becomes available on RedHat Enterprise or becomes default on Gentoo I'll start learning it. Even at that I'd probably be ready and have my code ported before it's possible to deploy it. At this point I'll guess that I'll be retired before 3.x is a default part of the RedHat Enterprise installation at my workplace.

Part of your answer - get RedHat to at least make Python-3.x optionally available, and some way to install alongside Python-2.6, as with Gentoo slots.

The future of Python 2

Posted Apr 27, 2013 14:56 UTC (Sat) by intgr (subscriber, #39733) [Link] (2 responses)

> At home I run Gentoo, and they have 2.7 and 3.2 both installed

What on Earth happened to Gentoo? It used to be an early adopter distro, but Python 3.3 was released in September 2012. Even fricking Ubuntu has Python 3.3 now.

Gentoo as an early adopter

Posted Apr 29, 2013 11:05 UTC (Mon) by shane (subscriber, #3335) [Link]

As a source-based distribution, Gentoo was always cautious with updating parts of the toolchain, like gcc. I suspect this is why Gentoo isn't running Python 3.4-pre-alpha1. :)

The future of Python 2

Posted Apr 29, 2013 11:47 UTC (Mon) by Duncan (guest, #6647) [Link]

Gentoo has had python 3.3.0 in-tree since 2012-10-30, according to its changelog, altho that commit message for it says "tentative... Some tests still fail."

On 2012-11-30, a 3.3.0-r1 ebuild was committed, along with revision bumps for other python slots, in a "cleanup".

As of 2013-04-28, Gentoo even has python-3.3.1. =:^)

So the reference in the grandparent wasn't to gentoo not /having/ 3.3, but rather, to what was installed on his system. Since gentoo has "slotted" python, individual python depending packages can specify the slots they can use, and individual users/installations can choose either an inclusive "deep" updates policy that keep everything updated to the latest it can use or a lazy "shallow" updates policy that only update dependencies when necessary, in addition to the stale^H^Hble/~arch (testing) choice, it's quite likely that either 3.3 wasn't unmasked to whatever he's running, or that he was using "shallow" updating policy and simply hadn't pulled it in.

Actually, a quick keyword check here shows that while 3.3.0, 3.3.0-r1, and 3.3.1 are all in-tree, at least for x86 and amd64, there's no 3.3-slot keyworded even to ~arch, let alone stable. Thus, they're available in-tree but keyword masked and won't be pulled in unless someone unmasks them. Presumably there's still quite a few dependency bugs being worked out, not even allowing slot 3.3 into ~arch/testing.

But it's there for those that want to unmask it, as I routinely do for various things, tho not python. (As a matter of fact, I've had =dev-lang/python-3* package.mask-ed for several years now, since it was first unmasked and portage tried to install it, so only 2.7 installed here. Presumably around 2015 when upstream 2.7 support drops, or when something I want/need python support for drops 2.x support, I'll finally unmask 3.x and hope everything I need "just works" with some standard 3.x by then, that I can standardize on as my single installed version again, as I am on 2.7 now.)

As a note of explanation, while gentoo does tend to be leading edge in many things, for toolchain and heavy-depended packages like gcc and python, while they're generally available in-tree early on, gentoo often takes longer to keyword them, both because there's slotting/unmasking available for those who have a need for a specific version so taking a bit longer to unmask isn't as huge a deal as it is on a distro (like the mentioned Red Hat) where there's (apparently) only one or a couple versions available, and because especially for things like gcc, the entire tree must be patched to build with the new version, and patched packages made available at the corresponding keyword level (~arch keyworded before gcc goes ~arch, stable before gcc goes stable), before gcc itself gets keyworded.

Of course people like me tend to unmask a new gcc early, pulling patches from the various bugs and dropping them in /etc/portage/patches/* as appropriate, even before they're applied to the corresponding ~arch packages...

python 3.3 is probably having similar keywording issues ATM. As I said I have 3.x entirely masked here so haven't paid that much attention to it, but IIRC I did see a comment on the dev list or on some bug or other that 3.3.1 should resolve most of the problems they were having, so I expect it will be unmasked in-tree fairly soon, while 3.3.0 wasn't as it had too many issues to deal with.