I think Python 3.0 is and will be a good thing even though it’ll create a staggering amount of work for me, my co-workers and my friends and colleagues (since I deal with two large Python 2.x codebases on a daily basis, the migration is not going to be simple or short for me).
So. Not a complete rewrite, but merely "a staggering amount of work"?
In other words, if you have five hundred instances of `print "foo"` which all need to change to `print("foo")`, it's not that you have to "completely rewrite", but you _do_ have five hundred changes to make. And since applying a change is almost never as simple as a single search/replace/rename, it means work.
2to3 will handle that automatically.
- Incorporate the -3 check with the usual unit tests and pylint run for checking a module as I work on it.
- Stay compatible with Py2.X and these additional checks, and when curiousity strikes, run 2to3 to see what happens. The codebase will probably grow some different idioms needed to clear up 2-vs-3 ambiguities; that's OK. I'll learn how to avoid these ambiguities as I go.
- When the community seems to be ready for 3.X (in particular, when Debian switches), most of the migration work will have already been done and the 2to3 script should work more or less perfectly for creating a new 3.X branch.