The slides of my keynote are now up on python.org. There's both a PowerPoint and a PDF file.

I'd like to take this opportunity to remind you of a really important issue that I neglected to mention in the talk: Don't change your APIs incompatibly when porting to Py3k.

Yes, you heard that right: even though Python 3.0 is changing incompatibly, I implore you (especially if you're maintaining a library that's used by others) not to make incompatible changes to your API. If you have make API changes, do them before you port to 3.0 -- release a version with the new API for Python 2.5, or 2.6 if you must. (Or do it later, after you've released a port to 3.0 without adding new features.)

Why? Think of your users. Suppose Ima Lumberjack has implemented a web 2.0 app for managing his sawmill. Ima is a happy user of your most excellent web 2.0 framework. Now Ima wants to upgrade his app to Py3k. He waits until you have ported your framework to Py3k. He does everything by the books, runs his source code through the 2to3 tool, and starts testing. Imagine his despair when the tests fail: how is he going to tell whether the breakage is due to your API changes or due to his own code not being Py3k-ready?

On the other hand, if port your web 2.0 framework to Py3k without making API changes, Ima's task is much more focused: the bugs he is left with after running 2to3 are definitely in his own code, which (presumably :-) he knows how to debug and fix.

The same recommendation applies even more strongly if your library is a dependency for other libraries -- due to the fan-out the pain caused to others multiplies. If one of those packages gives up (even temporarily) its Py3k porting effort, this may prevent many other libraries and apps from being ported at all!

So, once more for emphasis: Don't change your APIs at the same time as porting to Py3k!

Update: Martijn Faassen borrowed the time machine and wrote the same blog entry two weeks ago.

PS. The 3.0final release is now scheduled for September 3, 2008. See PEP 361.