I have spent many years in industry working for large companies that have big, successful internal Python code bases, with dependencies on large numbers of external packages. From talking about colleagues about migrating to new language versions, several issues come forward. They all conspire to make it hard to move forward, but not impossible. - A single external package that doesn't yet support the new version can block migration until it has been ported or been replaced by something else. - Many third party packages change their API as they move forward (sometimes they are forced by changes in the language). This means trouble in the backwards compatibility department. - A migration takes a lot of effort. You have to put several engineers on it full-time who could otherwise be developing new features; and it disturbs the development activities of many other engineers, who will be asked to fix tests, decide whether something is still used, and so on. - There are probably parts of the codebase that depend extensively on some feature that doesn't work in the new version, e.g. str/unicode equivalency. Yes, that code is probably buggy, but it is heavily used, and rewriting it means changing interfaces between different components, which in turn requires more rewrites. - There are probably different departments within the company that move at different speeds. It is extremely difficult to get everyone to switch at the same time. So you have to come up with some kind of gradual transition plan, which will probably make the effort even more work, by requiring backwards compatibility for some internal interfaces. - Even if everything goes extremely smoothly, you can still count on some interruption of production -- outages, performance degradations, all the things that end users notice and gripe about. The prospect of this makes managers *very* uncomfortable. But, despite all this, migrations happen all the time, and I am sure that Python 3 will prevail as time progresses. For many *users*, Python 3 may be a distraction. But for most *developers*, maintaining 2.7 is a distraction. By and large, users of 2.7 don't need new features, they just need it to keep working. And it does, of course. (At the risk of a flawed analogy: Windows XP is still the best version of Windows for hardware built when XP was current.) But perhaps we could change the focus for 2.7 development a bit: instead of fixing bugs (or bickering about whether something is a bug fix or a new feature) we could limit changes to ensuring that it works on newer platforms. Martin mentioned that building 2.7 for Windows with the same toolchain that was used for the 2.7.0 release is getting more and more problematic. I'm not sure, but I could imagine similar problems for future versions of OS X and even Linux (though the Linux distributions typically take care of issues themselves). There's not much of a point in fixing bugs that always existed in 2.7, since must 2.7 users are by now used to working around these. However, I do see a point in supporting builds targeting newer OS versions. This won't be much of a relief for Martin, but it might be one of the best ways to interpret "support" of Python 2.7 for the next several years. I would also support having a 3rd party doing this and sell the binaries for a small fee (ActiveState started out this way) -- but it would still behoove us to have the necessary build files in the core repo. Some final words: if any of the alternate Python implementations (IronPython, Jython, PyPy, even Cython) are feeling down on Python 3 because they do not have enough volunteers to help with the port (even though at least for IronPython and Jython, the new str/bytes model is much more suitable than the old), they should apply to the PSF for funding. I believe PyPy is already in the process of doing so. -- --Guido van Rossum (python.org/~guido)