[Python-Dev] draft pep: backwards compatibility

[Michael Foord]

glyph at 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 at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk 
>


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog