> Remember, Python 2 has both old-style and new-style classes, while Python 3 does not.

This logic is circular: you are directly claiming that Python 3 could not mix and match support with Python 2 because Python 3 does not support mixing and matching features with those from Python 2. Yes: I realize that, and that is precisely what I am taking issue with.

The reality is that supporting many of these features is actually quite simple. Please realize before disagreeing: I develop compilers, and I have developed virtual machines. I know what kind of effort it takes to have parameterized grammars and internal transformations.

What really seems to happen with Python is that people get it in their heads "developers should not be using this old feature", and then it gets actively removed in order to clear the mental space for the features that should be used: a "there's only one way to do it" mentality.

However, there is code out there that is using that feature, and that code might not have a maintainer anymore; that code works, has been battle-hardened, and the only thing keeping anyone from using it is now some arbitrary syntax change that was pushed through.

For an example of a community that gets this: C. No one develops in K&R C anymore. However, there is still tons of code out there, even code inside of some core projects you use every day, that was written in K&R C and never needed to get serious modifications made.

That code still works, and still compiles with modern C compilers. While the syntax is quite different, it really does not take much time to make certain your compiler supports it, and you suddenly have access to all of this totally working code: this should be considered a "win".

Yet, something in the Python community seems to latch on to the idea that that situation is actually a "lose": that having support for old features is only something that should be done in Python 3.3 (which isn't even out yet) as a concession to some reality as opposed to out-of-the-gate in 3.0.

Can you help explain this one to me? Why is it possible for Python 2.7 to have all of these really cool "from __future__ import" features, but impossible for Python 3 to have just a couple "from __past__ import" features? The only answer I currently have is "stubborness".

(Also, on the exception-handling semantics, it is only this year that a lot of key projects, from Jython to App Engine, have supported anything but Python 2.5; I accept that it is nice that 2.6 supported it, but a lot of real-world/serious Python was stuck in 2.5, so if you want your library to be widely used you couldn't use that syntax. The sea-change on this seemed to happen this year, so this should increasingly not be an issue, but it is way way too late and could have been remedied by supporting that syntax with a switch.)

(The same kind of failure, for the record, is demonstrated in the decision to finally fix a few of these issues--the u'' syntax not being the only one--in Python 3.3. Python 3.3 is not even out yet; when it is, it will not be deployed in many places, even places where Python 3.2 already is, such as the numerous Ubuntu servers that are already deployed. If Python wants to be serious about helping developers and making Python 3 actually happen, they should backport that change to Python 3.2 so it can be pushed through major distributions; otherwise, it just delays the benefits by yet another year, if not longer.)