On Feb 28, 2013, at 7:39 AM, Mark McLoughlin <mar...@redhat.com> wrote:
> I always felt that the Python community tended more towards the former > approach, but there always exceptions to the rule - to unfairly pick one > one project, sqlalchemy seems to have an API that often changes > incompatibly. For what it's worth, Twisted takes backwards compatibility very seriously. I try to mention this frequently in the hopes that more Python projects will adopt a similar policy: <http://twistedmatrix.com/trac/wiki/CompatibilityPolicy>. I hear that openstack has chosen to avail themselves of some different networking libraries... but you have deprived me of the opportunity for snark by apparently having no difficulty with compatibility in that layer :). Unfortunately, the tenor of the community has changed somewhat recently, with Python 3 being a clarion call for people who want to screw over their users with an incompatible release. There has been some cultural fallout from that, because it sets a bad example. Personally, I have found myself in a dozen serious conversations over the last two years or so when talking to other package maintainers (names withheld to protect the guilty) contemplating some massive incompatible change with no warning, because "everything is going to break anyway, so why not take the opportunity"; it's important that cooler heads prevail here :). Luckily, in most cases I was able to convince those folks that multiple simultaneous levels of breakage are a bad idea... However, many, perhaps even most, projects have made the transition gracefully without any API breakage, as we are attempting to, and to their credit, the core developers *have* said repeatedly that breaking API while porting to Python 3 is a singularly terrible idea. I see that most of your problems have been with PyParsing, though. PyParsing has also been infamously bad in terms of having no stable API, despite being well-post-1.0. When I last used it, the breakage was so bad that we just started bundling in a specific version in our code; even dot-releases were breaking things majorly. You can still see that here: <http://bazaar.launchpad.net/~divmod-dev/divmod.org/trunk/view/head:/Imaginary/imaginary/pyparsing.py>. Overall though, your impression of the Python community at large *is* accurate; breakages come with deprecation warnings beforehand, and mature packages try hard to maintain some semblance of a compatible API, even if there is some disagreement over what "compatible" means. -glyph
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
