The future of Python 2

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.