For those who don't read blogs, I just blogged the slides for my keynote, and added an important admonishment to 3rd party developers. Here's the full text of the blog: The slides of my `keynote`_ are now up on python.org. There's both a `PowerPoint`_ and a `PDF`_ file. .. _keynote: http://www.python.org/doc/essays/ppt/ .. _PowerPoint: http://www.python.org/doc/essays/ppt/pycon2008/Py3kAndYou.ppt .. _PDF: http://www.python.org/doc/essays/ppt/pycon2008/Py3kAndYou.pdf 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!** *PS.* The 3.0final release is now scheduled for September 3, 2008. See `PEP 361`_. .. _PEP 361: http://python.org/dev/peps/pep-0361/ -- --Guido van Rossum (home page: http://www.python.org/~guido/)