import_that: 2.8 inside a red circle with a line crossing it out (no-python2.8)
[personal profile] import_that
There's yet another call for Python 2.8, or at least for discussion for 2.8. Martijn Faassen discusses what Python 2.8 should be, even though it won't be. Frankly, I'm not entirely sure what motivates Martijn to write this post — he seems to have accepted that there won't be a Python 2.8 and isn't asking for that decision to be rethought., so I'm not entirely sure why he wants to discuss 2.8, but let's treat this as a serious suggestion.

Martijn suggests that, paradoxically, the best way to handle the Python 2.x to 3.x transition is for 2.8 to break backwards compatibility with 2.7. I thought we had that version. Isn't it called Python 3.x? Not according to Martijn, who wants to add — or rather since he explicitly says he won't be doing the work, he wants somebody else to add — a whole series of extra compiler options in the form of from __future3__ and from __past__ imports. Like __future__, they will presumably behave like compiler directives and change the behaviour of Python.

The idea, as I understand it, is that by providing a version 2.8 that breaks backward compatibility with 2.7, people will be more easily able to drop support for Python 2.6 and 2.7 in favour of 2.8, leaving them in a better position to migrate from 2.8 to 3.x later. Only, not quite: Martijn's explicitly notes that having come up with 2.8, we'll likely want a 2.9 after that:

People who have ported their code to Python 2.8 and have turned on all the __future3__ imports incrementally will be in a better place to port their code to Python 3. But to offer a more incremental step, we can have a Python 2.9 that requires the __future3__ imports introduced by Python 2.8. And by then we might have thought of some other ways to smoothen[sic] the upgrade path.

Presumably followed by a 2.10, 2.11, 2.12, ... incrementally getting closer and closer to the ever-advancing 3.x series.

Like so many of these proposals, I think that Martijn's proposal falls down on two fundamental points:

  • If people aren't willing or able to deal with lack of compatibility between 2.x and 3.x, what makes him think that they will be willing or able to deal with lack of compatibility between 2.x and 2.8?

  • Even if they are, having gone through the painful process of one migration to a version which deliberately breaks their 2.7 code, they then have to go through a second similarly painful migration just a few years later. Who wants to do that?

The success, if any, of this strategy hinges on people dropping support for 2.7 and older. (But if they could do that, why haven't they already done so?) That's absolutely critical. Assuming 2.8 somehow comes into existence — I don't see many people volunteering to create it — how likely is it that people will use it? In my opinion, not very.

Firstly, Martijn's plan relies on libraries dropping support for 2.7 and older and only offering support for 2.8 and above. But why would they do that? I think it is terribly naïve to expect that libraries will drop support for 2.x just because 2.8 is available. There are popular libraries and frameworks still supporting Python 2.3. If libraries were willing to abandon 90% of their users and drop support for the two most popular production versions of Python, why wouldn't they go straight to 3.x?

Unfortunately, given how critical it is for his plan that libraries drop support for 2.7 and older, Martijn gives no reason why they might do so, except that he thinks that supporting 2.8 plus 3.x will be easier than supporting 2.x and 3.x. What's even easier is just supporting 3.x. Libraries don't choose what versions to support just based on what's easier. If this backwards-incompatible 2.8 came into existence, I expect that libraries would be forced to deal with not two but three mutually-incompatible dialects of Python: vanilla 2.x, the backwards-incompatible 2.8, and 3.x. For library developers, supporting 2.x and 3.x is an on-going cost, and adding 2.8 increases that cost significantly.

But without dropping that support for older 2.x versions, Martijn's plan collapses. Broadly speaking, there are two reasons why people might migrate to Python 3, or Martijn's 2.8: the carrot ("Look at all the great new features! I want to use them!") and the stick ("Oh no, I'm going to be left without upstream support, there will be no bug fixes and security updates."). If the carrot alone was sufficient, people would have migrated to Python 3 already (that's what drives the early adopters). Without the stick, the natural inertia of development will keep people on whatever version they are currently using. Why spend time and money upgrading a working system when you don't have to?

Unless libraries abandon 2.7 (which they won't do), it is very likely that the only people who will migrate to 2.8 will be those who would have migrated to 3.x. Instead of encouraging migration to 3.x, 2.8 will discourage it, and split the community even further into three groups, those who migrate to 3.x, those who migrate to 2.8, and those who don't migrate at all.

Of course, there is still the stick of Python 2.x reaching end-of-life, but that's a far-off stick and not yet a credible threat to force people to migrate. That's deliberate, not an accident. Guido van Rossum and the Python core developers have no intention of forcing people to migrate earlier than necessary, and are intentionally providing long-term support for Python 2.7 until 2020 so that application developers won't feel pressured to move to 3.x unnecessarily. Beyond that Red Hat is providing commercial support until 4th quarter of 2023.

This 2.8 proposal will disadvantage library and framework developers. How about application developers? They usually have more flexibility in standardizing on a single version of Python, assuming that their dependencies support that version. For applications, migrating to Python 3.x is a once-off cost, and like all such costs, people will be reluctant to pay it unless they get sufficient benefit. Martijn's proposal increases their costs too: first you migrate to 2.8, then later you migrate to 3.x. The total migration cost won't be less: at best it requires the same amount of effort, merely be spread out over more time, at worst it will take double the effort. Even if the total migration effort is no more than going directly to 3.x, I expect that the social cost will be significantly greater. Two backwards-incompatible migrations is a harder thing to sell than one: "What do you mean, we have to upgrade again? We just did that a few years ago?"

My feeling is Martijn's 2.8 would do nothing to increase take-up of Python 3.x by application developers, it will likely decrease it as many people who otherwise would have taken the step from 2.7 to 3.x instead decide to take the half-step to 2.8 and stay there indefinitely. But for the rest of the Python community, it would just increase the pain level for no benefit: libraries and frameworks would be forced to support three rather than two dialects, Python forums would have to deal with users using any combination of the three, beginners would be even more confused, tutorials for 2.8 would have to introduce the advanced from __future3__ import ... right from the beginning, and there would be three distinct versions of Python to maintain for the next five or ten years.

It seems to me that if you wanted to inconvenience Python developers even more, drive them away to other languages, you could hardly do better than introduce a 2.8 as Martijn suggests.

As I see it, many people asking for 2.8 don't really have a migration path to 3.x in mind. Calls for Python 2.8 are often (but not always) a way to avoid migrating — "We really, really don't want to migrate, why can't you backport all the good stuff that we care about, and none of the stuff we don't care about, to Python 2.8 so we never need deal with Python 3 at all?" (The problem being that the "good stuff" Fred wants backported is probably not the same as the "good stuff" Barney wants backported.) Martijn's proposal won't satisfy those people either, since it involves breaking compatibility with 2.7 and they're completely happy with sticking with 2.7. For some people, it really may be the case that the benefits of Python 3 will never outweigh the cost of migrating, and the best solution really is to just stick to 2.7 indefinitely. There's no shame in that, it's just common sense. If on-going support and security fixes and new features have little value to you, then why should you pay the cost for them? There are people still happily using Python 1.5, more than fifteen years since its last release. Good for them. There's no use-by-dates on source code.

Of course, most people will, eventually, want to migrate to Python 3 in order to keep up with bug fixes and security updates, and to take advantage of new features. Except for Unicode, for those who need Unicode, 3.x hasn't offered any killer new features, just incremental improvements, so the non-adapters do have a point: the cost of migration is higher than the benefit to them. But that's likely to get better, not worse. Each new release of 3.x adds new features, and makes it easier to migrate than the previous version. 3.2 was easier to migrate to than 3.1, and 3.3 easier to 3.2, and 3.4 easier than 3.3. I expect that 3.5 will offer more benefits and lower migration costs. The Zen of Python applies to application developers too:

Now is better than never.
Although never is often better than *right* now.

Waiting for 3.5 or 3.6 is a perfectly good strategy, and far more productive than waiting for 2.8. Even if the Python core developers got 100% behind this idea and started working on it immediately, 2.8 would be highly unlikely to be ready for production use for at least 18 months. Add some time for libraries to migrate away from 2.x and to 2.8, that makes probably two or three years before applications can even begin their migration to 2.8, which is when Python 3.5 and perhaps even 3.6 will be available. It simply doesn't make sense to make two backwards-incompatible migrations instead of one.
Identity URL: 
Account name:
If you don't have an account you can create one now.
HTML doesn't work in the subject.


If you are unable to use this captcha for any reason, please contact us by email at

Notice: This account is set to log the IP addresses of everyone who comments.
Links will be displayed as unclickable URLs to help prevent spam.


import_that: XKCD guy flying with Python (Default)
Steven D'Aprano

May 2015

345678 9

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags