Oops! I thought 3.3 was already out. I see it's only a release candidate.

Get this into your head - Python has a different development model than C. There is no standards body, or requirements for backwards compatibility. Anyone who gets into Python thinking that there will be full backwards compatibility is fooling themselves.

Those who want backwards compatibility can do so on one of several ways: 1) keep using the old code and don't upgrade, 2) contribute time, effort, and funding to the core developer team in order to implement backwards compatibility, 3) fork and maintain your own version of the source, 4) make your own run-time hooks to convert old-style Python code to the new-style runtime, or 5) create a new version of Python which does have that backwards compatibility.

I know that REXX and a few other languages have made a point of backwards compatibility even as semantics change. They have different goals, and a different funding model than Python. If enough people disagree, then those people can take the existing Python code base and run with it. But that's not happening. (I think there are some unofficial patches with VC2010 support, mostly used for internal company builds.)

There's, what, a few score people working part time in Python code development? Even Guido works on it only half time. How do you expect that small of a team to pull off a clean 3.0 release without making mistakes? The 3.0 release had a new io system, which was a lot slower than 2.x. There were a lot of bugs, like unicode filenames, which had to be figured out, where previously it was the responsibility of each developer to figure out the Unicode issues.

"Can you help explain this one to me? Why is it ... impossible for Python 3 to have just a couple "from __past__ import" features?"

That's an easy one. Lack of resources. The Python code developers did not want to maintain both old-style and new-style class implementations. They used Python 3 as a way to get rid of old-style. As a consequence too, it means that I can stop putting in the silly 'object' in "class Spam(object):", which was the Python 2 way of indicating that I wanted a new-style class. If 5 people said that they were willing to support old-style classes, and showed that they were committed to doing so for many years, then there may have been a different decision.

You can see that even in the PEP 3000, written during the 2.6 days: "But I expect there to be at least one or two new 2.x releases even after 3.0 (final) has been released, probably well into 3.1 or 3.2. This will to some extent depend on community demand for continued 2.x support, acceptance and stability of 3.0, and volunteer stamina." (Emphasis mine.)

So many other things had deeper semantic changes, like dict.keys returning a view rather than a list, that a simple syntax change is trivial. I don't think a "from __past__ import comma_exceptions" would have had much benefit. I can be wrong, but that's exactly the thing that the 2to3 converter could handle, and there are patches to make distutils convert 2.x code automatically and import hooks to do that transformation at run-time. One such is pymolurus.blogspot.com/2012/04/pep-414-like-import-hook-for-python-32.html . It isn't a catch-all solution, but that approach could help some people.

BTW, as far as I can tell, clang does not support K&R C.