The potential for a Python 2.8.
There has recently been some discussion about Python 3, and the percieved slow rate of adoption, and as a part of that discussion there have been frequent calls for a Python 2.8. But nobobody agrees with anyone else about anything in that discussin, so I thought I would dissect the issue a bit to clarify.
Essentially there are two different views of Python 2.8. It’s common to hear people asking for a Python 2.8 to help transition to Python 3. Let’s call that a “transitional Python 2.8″. The other group that wants a Python 2.8 want it because they want all the new goodie features of Python 3.x, like
yield from, without having to actually upgrade their existing code to Python 3. I’ll call that the “featuristic Python 2.8″.
The Featuristic Python 2.8
Python 3 is in active development, and do have new features added to it. Python 2 is in bugfix mode. Why is that? Well, it’s simply because the core developers aren’t interested in adding features to Python 2. In their opinion Python 3 is so much better and nicer that thay no longer want to maintain or add features to Python 2. In fact, Python 3 exists because there were features the core developers wanted that could not be added to Python in a fully backwards compatible way.
Therefore, from the core developers point of view, if we add the features they want to Python 2, you get Python 3. You ask for a Python 2 with the goodies from Python 3? OK, here, it’s called Python 3. So the core developers are not interested in creating a Python 2.8 that includes just some of the benefits of Python 3. That’s just a lot of work, but for them it creates no benefit. A Featuristic Python 2.8 is essentially just a crippled Python 3.4.
And that features are added to the latest version and earlier versions are in bug fix mode is after all the standard mode of development. To ease transition, both Python 2.6 and 2.7 has been released, but this can’t continue for ever, for obvious reasons.
Does that mean a Python 2.8 can not happen? No, it can. If the Python core developers decide that Python 3 was a dead end, then obviously a Python 2.8 will happen. But that is a big if, and it certainly isn’t going to happen anytime soon. The other way it can happen if somebody forks Python 2, and makes a Python 2.8. It will have to be released under another name, though, but should “Psnakes 2.8″ become a big success, this may also change the core developers minds.
But asking the core developers to make a Python 2.8 and release it is currently not a constructive path forward. They are not interested in doing it. And being upset and rude isn’t gonna help either. This is open source we are talking about, and people working on their free time. You can demand that they do something they don’t want to, and call them names if they don’t. It’s not constructive.
So, if you want “Psnakes 2.8″ what should you do? Well, stop complaining and do it. I’m sorry, but that’s how it is in open source. If nobody wants to do the job, it’s not going to get done.
The Transitional Python 2.8
The other major type of Python 2.8 being discussed is a Python 2.8 that helps smooth the transition to Python 3. Mainly this would be done by making it easier to write code that runs both on Python 2.8 and Python 3 (mainly Python 3.5, probably). Could that happen? Well, I think it will be much easier to convince the core devs to release this kind of Python 2.8, if the need is there. The question then is if the need really is there. What features can you add to a Python 2.8 so that it is still backwards compatible, makes it easier to write code that runs on both Python 2.8 and Python 3, but can not be added in a separate library?
Well, *that* is an interesting discussion, and I have asked this to many people over the last year(s). And usually nobody has any suggestions. The only suggestions I have recieved so far is:
1. Include the standard library reorganisation, so that libraries are available under both the new and old names.
2. More deprecation warnings.
six helps with the standard library reorganisation, so that doesn’t really require a Python 2.8. More deprecation warnings to require a Python 2.8, but I’m not sure how helpful that would be. After all, the best path to supporting Python 3 (at least in my experience) includes runninge
2to3 on the code, so having deprecation warnings for anything that is handled by
2to3 is probably not very important.
I can think of more things, but I’m not telling, because I want people who have tried to port to tell me what features they actually want.
So in my opinion, the potential for a Transitional Python 2.8 isn’t that large either, simply because it’s not really needed. Upgrading to Python 3 *can* be a lot of work. But I’m not sure a Python 2.8 would make it significantly easier. But I’m willing to be convinced otherwise.