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.