[Python-Dev] Open issues for 2.4.1
tim.peters at gmail.com
Sat Mar 12 20:31:57 CET 2005
> So here's a list of open items I'm thinking about for the 2.4.1
> [... 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,
> 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
> 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
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!
More information about the Python-Dev