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.. 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 > > Unsubscribe: > > --