[Anthony Baxter] > So here's a list of open items I'm thinking about for the 2.4.1 > release. > > [... sorry, but my editor automatically deletes all paragraphs > mentioning problems with Unicode ...]
> - The unitest changes> Changes to unitest to fix subclassing broke Zope's > unittests. Should this change be reverted before 2.4.1, No. > or was the Zope test suite doing something particularly dodgy? Yes, it was overriding a documented, public method, but with no awareness that it was overriding anything -- a subclass just happened to define a method with the same name as an advertised unittest base class method. > I'm talking about > - unittest.TestCase.run() and unittest.TestSuite.run() can now be > successfully extended or overridden by subclasses. Formerly, > the subclassed method would be ignored by the rest of the module. > (Bug #1078905). Since there was no _intent_ in the zdaemon tests to override run(), it's just an accident that unittest used to ignore run() overrides. The fix in zdaemon source was s/run/_run/g. It shouldn't have used "run" to begin with. > I've not looked too closely at the broken Zope code - can someone from > ZC comment? Not officially <wink>. > How likely is it that other programs will also have been broken by this? Approximately equal to the odds that someone else defined a method named "run()" in a TestCase or TestSuite subclass without realizing they were actually overriding an advertised base class method (but one that didn't actually work as advertised, so there was no visible consequence before). ZC has a relatively huge number of test suites, and it should be noted that only the zdaemon suite was affected by this. Since the zdaemon tests don't run at all on Windows, I never noticed this; if I had, I would have changed the zdaemon test source as a matter of course (i.e., the thought "Python bug" wouldn't have crossed my mind in this case). > At this point, I'm leaning (very slightly) towards the feeling that this > should > probably be backed out before 2.4.1, mostly because it seems to me that > this is an incompatibility, rather than a pure bug fix. It looked like pilot error on zdaemon's side. > I'm now pretty sure we need a 2.4.1rc2 for this week, and a 2.4.1 final the > week after. There's been a few too many changes for my tastes to say that > going straight to a 2.4.1 final is a prudent course of action. OK by me! _______________________________________________ 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