There's a hand-wringing coversation today on the Python list where someone suggested making 2.7 "the last Python in the 2.X series", giving the rationale that people really should be using 3.X and that dropping maintenance for 2.X will give them a reason to move.

I say hooray! But not for the reason you think.

Now I'm pretty sure there will be a Python 2.8, 2.9, and 2.10, 2.11 and so on as sure as the sun will rise. These releases may not be prepared by the same people who have the responsibility of creating releases today, but other folks will probably pop up to fill in for them, even if only unofficially.

But even if there isn't another blessed Python 2 release from the "core team", that's OK. Worse is better.

I get the sense that the folks who are currently pushing new Python releases aren't really that interested in making sure old code runs "forever". It was a tipoff when version 3 started out with minor backwards incompatiblities, of course. This isn't very surprising. Preserving backwards compatibility in complex systems is really just no fun. It's an ugly, thankless slog. Your mistakes stare you in the face daily. It's a lot more fun to do greenfields projects like Python 3000. We all love green-fielding things. (BTW, I think PEP 3003 might declare playtime over though).

In the meantime, though, old Python code never dies, and must continue to run, even when nobody understands it fully any more. With a Python 2 that is very conservatively maintained (or even un-maintained), this is won't be much of a problem. Because there won't be new features, there just won't be any backwards compatibility problems. If Python 2.8 was released as just a set of patches that made Python 2 compile against the latest and greatest set of operating system updates from the major vendors, and had no other changes, fantastic. For legacy systems I maintain, that's change I can believe in. Give me more of that!

I fear that in the actual world, code stability provides more benefit than new syntactical candy and included batteries and obsessive reorganization. It's going to take a long time for people to switch to Python 3. You can try to speed up the process by shepherding people along some decision tree, but they're going to do things at their own pace no matter what decisions you try to make for them. You may want them to arrive at a decision like "I'm going to rewrite this code I barely understand anymore in a backwards incompatible variant of the programming language it was originally written in". That's a reasonable desire. But if the only other choice you provide to them other than that one is "maintain the old programming language version myself", you are only implicitly leaving out the choice "or just rewrite the system in a different language altogether". This implicit choice is often the one people make when they are led along some artificial decision tree.

If a new version of something is not 100% backwards compatible, I think you just need to let the old version and the new version compete on the field of mindshare instead of declaring one the royal blessed successor to the other, and artificially mandating that releases of the old version won't be made. There's no guarantee that today's Python 2 code will become tomorrow's Python 3 code. And that's OK. Python 2 is a fantastic language.