Python 3000 migration

I think it's a good thing that Python as a language removes some of its deprecated features and old special cases which no longer make sense.
Few programming languages make such a bold move, although more should. A language that grows ever more complex with time becomes a huge liability. Much of this complexity is unavoidable, but the avoidable one should be avoided! Making the necessary non-backward-compatible changes to a language is an expensive investment because the migration of existing libraries and applications becomes a project of its own for each of those libraries and applications. On the other hand, this investment also has an immense payoff in maintainability and extensibility in the long term.

Now, it has been more than six months since Python 3.0 has been released, but a naive search on Google doesn't turn up any migration information yet! Some people seem to have plans for migration, but there's no experience-report yet. Also, there is no list of libraries that have already moved or are planning to move. Unfortunately it seems that no application or library can be migrated until all of it's dependent libraries have done so. Of course, a project could migrate to 2.6, import feature from future and use the -3 compatibility checking option. But it seems that most are still waiting for the "upstream" projects to move.

Here are some references:

• PEP 3000 - "guidelines for Python 3000 development" by Guido van Rossum
• http://peadrop.com/blog/2009/04/05/porting-your-code-to-python-3/ 
• How are you planning on handling the migration to Python 3? - Discussion on stackoverflow.com

After the 3.0 release it quickly turned out that GvR's original advice: "start all your new projects with Python 3000" is unrealistic: the libraries are just not there yet. But what's realistic (and what I will do) is to write all new code with Python 2.6 and make it as much future-compatible as possible. Then the port to 3.x will be completely automatic, once the new libraries have come out.