With both 2.6b2 and 3.0b2 out the door, the next due date for python-dev is August 13, when b3 is scheduled to be released. The big deal with that is b3 is the last planned beta; only release candidates and the final release will (supposedly) be left.
There are currently 14 release blockers. This can easily change, though, thanks to issues being fixed and developers also prioritizing other issues to the level of a release blocker (like I did just before this blog post =). That is not an insurmountable number to close in ten days. The current list is a mix of features to finish implementing, making decisions on some warnings that are currently being emitted, and just some general bugs.
I have personally been working on eliminating warnings generated by code in the standard library when the interpreter is run under the '-3' flag (that turns on warnings for 3.0 compatibility). Almost every change has been minor; mostly tuple unpacking in parameter lists (which makes it only fair that I be the one to remove that since I deprecated the feature). It's nothing difficult, but does take some time. To make it go faster I am ignoring warnings from unit tests themselves and only worrying about stuff triggered directly within standard library code.
As of late I have been thinking about what I can do to try to get people to transition off of the 2.x branch of Python and over to 3.0. Using the carrot/stick analogy, the stick will be when (I assume) more and more core developers stop worrying about 2.x and focus work on 3.x. Eventually 2.x might be put into pure maintenance mode and certain bug fixes won't be backported because they break compatibility.
As for the carrot, that will come from new features that are simply not backported to 2.x. For my part, I plan to have importlib be a 3.1 exclusive to try to get people to upgrade. Some minor stuff might get backported (e.g, some new interface that allows code to more programmatically import modules), but otherwise my rewrite will most likely not be added to 2.x. Hopefully features will continue to come in to 3.x that will draw people over.
And the idea of a 3to2 tool is still a possibility. If more code is written in 3.x to start and 2.x is viewed more for compatibility with legacy stuff, then hopefully more people will switch. I don't know if a 3to2 will ever come into existence, but I think it could be useful (although adding warnings for stuff only in 3.x would suck).
Anyway, we will see how things shake out over the years (and I do mean years; no one expects a massive transition to 3.0 overnight).
