[Python-Dev] 3rd party developers: don't change your APIs when porting to Py3k!

[Guido van Rossum]

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/)