
glyph@divmod.com wrote:
[snip...]
For example, I think it was wrong to change the name of a test-skipping unittest method just so that it wouldn't clash with a method created by Twisted subclassing unittest (besides, self.skip() was much nicer than self.skipTest() ;-)). Just because some class is public shouldn't prevent us to add new public methods or attributes to it.
I think it would be wrong to have a blanket prohibition on such changes, by which I mean additions of names to public namespaces. Twisted's own compatibility possibility would not forbid a similar change. But in that specific case I think it was the right thing to do. Like it or not, a lot of people use Twisted, a lot of people run tests with Trial, and we beat stdlib unittest to the punch on the 'skip' testing feature by a good 5 years. We caught the change well before the release, we reported it and discussed it.
Just to note that Twisted (along with Bazaar) are one of the few 'good citizens' in the Python community running their tests on Python trunk. Both projects have caught incompatibilities *before* release of new versions which is greatly preferable to discovering them after a release. Thanks for this. Michael Foordt
IMHO this is the best way to deal with incompatible changes, especially in the case of superclasses, given Python's subtle and complex inheritance semantics. It's not feasible to provide a policy that somehow prohibits subclasses from adding names which may eventually be used on a superclass.
Projects which notice test failures with new versions of Python should report them so that the features can be adjusted to be compatible, assuming the project in question hasn't done anything in egregious violation of the compatibility policy (like invoking a private method). This lets users, system administrators, and application authors upgrade components individually, without worrying about the components further down the stack flaking out on them. It also provides a feedback loop for the compatibility policy: if there are things that initially seem reasonable, but projects report compatibility issues when they are changed, they might need to be added later. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog