Against the Alexandria Library Migration Strategy

Some library maintainers, when faced with the impending incompatible changes in Py3K, decide that it's time to burn their library down and start over with a new, incompatible version. "Python is changing", they say, "so people are going to have to do a bunch of maintenance anyway. What a great opportunity to force them to do all that maintenance that they should be doing for our library too!"

I'm saying it's wrong. But don't take my word for it: Guido says it's wrong. Before it became cool to do it, Martijn Faassen was saying it was wrong.

Guido didn't just blog that it was wrong, though. He was so concerned that this message get out publicly that he repeated himself in a mailing list message to python-dev to make sure that people who don't read blogs would get the message.

This might strike some library maintainers as unfair. If Py3K is just breaking compatibility, why can't you?

First of all, even if Py3K were really "just breaking compatibility", there is still the issue of careful timing. You should read Guido's post and understand Ima Lumberjack's plight; he explains it exactly as I would. When your users are doing maintenance to upgrade something, they only want to upgrade one thing, so they know what's going wrong when they encounter problems. And if you're making incompatible changes, they will encounter problems, regardless of how cool and well-documented your new API is.

But, if you look closely, you will find that there's another reason that your library doesn't play by the same rules that Py3K does. It's because Py3K is actually doing a lot more than just breaking compatibility.

I've been a critic of this effort in the past (and I still occasionally grumble about a thing or two) but the bottom line is that the core Python team is not just willy-nilly breaking stuff. Let me enumerate the huge amount of work they're doing to make sure that people can have a reasonable migration experience to Python 3:

The Python core team have written and are maintaining a source-to-source translation tool to assist in the transition. Does your compatibility-breaking project have source-to-source translation, or in fact any tool support for migrating between different versions of the library?
The Python core team are developing a compatible backport of 99% of their features: Python 2.6 is effectively "python 3 lite"; you don't need to upgrade all the way to the incompatible version to get a lot of the new features. Does your compatibility-breaking project include a (at least mostly) compatible backport of all of your new features to an actively developed, "older" version?
The Python core team is providing long-term support for the previous version so that people can migrate at their own pace and not be left out in the cold. Is your compatibility-breaking project planning to provide a decade worth of bugfixes, security patches, and feature backports to your older versions?
The Python core team is providing comprehensive deprecation warnings explaining each new feature, and how you get there from the old feature. Is your project going to provide documentation like that?

It's also worth noting that Python's dependencies are not going through any kind of compatibility earthquake while they're doing this, so they are not in the same position that you (as a Python application author) are.

So, if you answered "yes" to all four of those questions — you still don't have the same excuse that Python does, because their dependencies are not changing incompatibly. So don't do it. But if you were thinking about breaking compatibility at the same time as a dependency, then you probably didn't.

Of course, you can drop deprecated stuff and break compatibility if your user community will tolerate that. Just don't do it in the same version where you decide to support Py3K. Users should have the ability to get a compatible version that will work in 2.x and 3.x so that when they translate their own source code, they don't have to learn new methods right at that moment.