gl...@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.uk
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
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/archive%40mail-archive.com
