Debating a "transitional" Python 2.8

Python 3 has been around for five years now, but adoption of the language still languishes—at least according to some. It is a common problem for projects that make non-backward-compatible changes, but it is even more difficult for programming languages. There is, typically, a huge body of installed code and, for Python, libraries that need to be upgraded as well. If the new features aren't compelling enough, and the previous version is already quite capable, it can lead to slow adoption of the new version—and frustration for some of its developers. Solving that problem for Python 3 is on the minds of some.

Recently, Alex Gaynor, who has worked on core Python and PyPy, expressed his concerns that Python 3 would never take off, partly because the benefits it brings are not significant enough to cause projects and users to switch over to Python 3. After five years, few are downloading packages for Python 3 and developers aren't moving to it either:

That leads to language stagnation at some level, Gaynor said. Everyone is still using Python 2, so none of the features in 3.x are getting exercised. Since Python 2 is feature frozen, all of the new features go into versions that few are using. And it is mostly Python-language developers (or others closely related to the project) who are using the new features; the majority of "real" users are not, so the feedback on those features may be distorted:

Gaynor concluded that the divergence of Python 2 and 3 has been bad for the community. He suggested releasing a Python 2.8 that backported all of the features from Python 3 and emitted warnings for constructs that would not work in Python 3. That, he said, would give users a path for moving to Python 3—and a way to start exercising its new features.

As might be guessed, not all were in favor of his plan, but the frustration over the Python 3 adoption rate seems fairly widespread—at least with the commenters on Gaynor's blog. So far, the conversation has not spilled over to python-ideas or some other mailing list.

Alan Franzoni agreed that some kind of transition path, rather than an abrupt jump, is needed.

David A. Wheeler and others agreed with Franzoni, but "rwdim" felt that Gaynor did not go far enough:

In addition, rwdim suggested that the Python package index (PyPI) stop serving packages that are not Python 3 compatible at some point. That last suggestion was not well received by PyPI maintainers and others, but it did attract other semi-belligerent comments. For example, "jgmitzen" likens users sticking with 2.x to terrorists (and to the Tea Party in another comment). While perhaps a bit overwrought, jgmitzen's point is that supporting 2.x in the Python ecosystem is taking time and energy away from 3.x—to the detriment of the language.

But "gsnedders" is not sure that a 2.8 really brings anything to the table. In the libraries that gsnedders maintains, things have gotten to the point where a single code base can support both >=2.6 and 3.x, and that should be true for most projects. The more recent feature additions for Python 3 are in the standard library, which means they are available for 2.x via PyPI.

Like rwdim, Sean Jensen-Grey would like to see an evolutionary approach so that a single interpreter can be used with both Python 2 and 3. In another comment, he referenced a March 2012 blog post from Aaron Swartz that outlines his vision of how the Python 3 transition should have worked. It followed the established pattern of adding new features to Python 2.x, which is clearly an evolutionary approach.

But Python 3 set out with a non-evolutionary approach. Python Enhancement Proposal (PEP) 3000 clearly specified a break with 2.x backward compatibility. The question seems to be: is it time to rethink that strategy in light of the slow adoption for Python 3?

It may simply be a matter of time, too. Linux distributions are starting to plan for shipping Python 3 as the default—some already have made the switch. Those kinds of changes can only help spur adoption, though it may still take a while.

In addition, Some don't seem convinced that Python 3 adoption is lagging, or at least that it is lagging as badly as is sometimes portrayed. To start to answer that question, Dan Stromberg has put together a survey on Python 2.x/3.x use. Whatever the outcome of that, though, it seems likely that many core developers are less than completely pleased with where Python 3 uptake is today—and will be looking for ways to improve it.