The future of Python 2

Python 3 has been out for close to four and a half years now—since December 2008—but its widespread adoption is still a ways off. Python 2.7 is younger—released in July 2010—but it is likely more commonly used than 3.x. In fact, usage of Python 2.x dwarfs that of the incompatible "next generation" Python. But with frameworks like Django and Twisted having been ported to Python 3.3, there is something of a feeling of inevitability for an eventual Python-3-only (or mostly) world. The only question is: how soon is eventual?

There are at least two questions floating around in the Python community with regard to future versions. One concerns how many more 2.7 releases there will be past the early April release of 2.7.4, while the other is a bit more amorphous: when will adoption of Python 3 really start to ramp up? The two questions are related, of course, but the problem is that the less knowable one will to a large extent govern how long 2.7 releases will be needed.

2.7 release manager Benjamin Peterson kicked off the discussion with a post provocatively titled "The end of 2.7". In it he posited that five years of maintenance was what was promised back when 2.7 was released in 2010, which would mean roughly another four six-monthly releases before 2.7 (and thus Python 2.x) would reach end of life. There were some questions about where Python 3 adoption would be by then, but there was no real opposition to Peterson's plan.

But there are the bigger questions. As was pointed out in the thread, there are still users of various end-of-life branches of the Python tree, including 2.4 and even 1.5. Those users are either happy with the existing version and unconcerned about security and other bug fixes—or they get support from one of the enterprise distributions such as RHEL, SUSE, or Ubuntu LTS. Contentment with those versions is not the only reason people stick with them, though, as there are real barriers to upgrading—especially to Python 3.

As Python creator (and the language's BDFL, benevolent dictator for life) Guido van Rossum put it, there are several issues that make migrating a large code base to a new Python version difficult and "they all conspire to make it hard to move forward, but not impossible". He goes on to outline those problems, which are largely comprised of the number of people and amount of time required, difficulties with external libraries and frameworks, and the general upheaval caused by such a move. Ultimately, though, he is optimistic:

Some suggestions in the thread that it is relatively straightforward to move to Python 3 by using tools like the six compatibility library were shot down by others. For example, Skip Montanaro noted that some code bases long predate the existence of six, or even Python 3. But it has gotten easier over time to migrate because new features have been added (or old features revived) to ease the transition. As Barry Warsaw pointed out, the Python developers have been learning from earlier porting efforts:

Van Rossum suggested that perhaps slowing down or stopping bug fixing in 2.7 might be the right course. Users have already worked around or otherwise dealt with any bugs they have run into. Ensuring that 2.7 continues to work on new releases of Windows and OS X (Linux too, but distributions normally take care of that) would instead be the focus. But there are some areas that do need new features; the IDLE IDE from the standard library has been mentioned as one area where bug fixes are needed.

Another interesting case is PyPy, which is an implementation of the Python language written in (a subset of) Python 2.7. Even PyPy3k, which will take Python 3 as input, is still written in RPython (restricted Python) based on 2.7. That means that the PyPy project will still be maintaining the 2.7 standard library for longer than the two years Peterson plans, as Maciej Fijalkowski noted.

When Martin von Löwis posited that it must be library support that leaves people "stuck" with Python 2, Fijalkowski was quick to point out another reason, at least for PyPy:

That problem is not limited to PyPy of course, there are lots of Python applications where the version of the underlying source code is not of any particular interest to users. The users want an application that works and regularly has new features, both of which could be negatively impacted by a Python version migration.

The consensus in the thread seems to be that Python 3 usage is increasing, and perhaps even reaching a tipping point because of recent migrations by frameworks like Django and Twisted. But Raymond Hettinger reminded everyone of the informal survey he conducted in his recent PyCon keynote, which found that out of roughly 2500 people, "almost everyone indicated that they had tried out Python 3.x and almost no one was using it in production or writing code for it". On the other hand, Ian Ozsvald has collected some data suggesting that Python 3 uptake is increasing.

In the final analysis, it won't be clear when (or if, though that outcome seems rather unlikely) a tipping point is reached until well after it happens. It is a bold step—some would say foolhardy—to change a language in a backward incompatible way as Python has done. It is not hard to see that any change of that sort will take some transitioning time. But the Python core developers are signaling that they believe the tipping point is at least in sight; anyone who has been blithely counting on 2.7 support continuing "forever" clearly needs to start at least thinking about their plans for the end of Python 2.7.