[Python-Dev] unittest.TestSuite holding references to unittest.TestCase instances too long
fuzzyman at voidspace.org.uk
Tue Aug 6 10:25:14 CEST 2013
On 6 Aug 2013, at 00:43, Matt McClure <matthewlmcclure at gmail.com> wrote:
> On Sat, Aug 3, 2013 at 3:27 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> It smells to me like a new feature rather than a bugfix, and it's a moderately big change. I don't think it can be backported to 2.7 other than through unittest2.
> Is http://hg.python.org/unittest2 the place to backport to unittest2?
It is, but... unittest itself has changed so extensively since the last release of unittest2 that I'm not sure whether a completely fresh start for unittest2 might be needed. (Although I intend to do another bugfix release of this version as well.)
Making unittest2 will involve:
* Taking the Python 3 unittest and porting code plus tests to run on python 2
* Run the new plus old tests (removing duplications) to ensure no functionality was lost (for example string handling will be wildly different so some tests may have been removed in Python 3 that are still relevant to Python 2)
* Fix the failing tests and decide whether new features that depend on later versions of Python (particularly around improvements to the inspect module and stack frames) even *can* be backported
* unittest2 classes all need to inherit from the unittest versions (and do some appropriate super calls because of the extra base class) - plus there are some tests for the differences
* there is a setuptools compatible test runner and the unit2 script also additional to vanilla unittest
* documentation updates - new features and differences
* stuff I've forgotten
So it's a pretty big job, but not insurmountable :-) A version that targets Python 3.2 would also be useful - it *may* be possible to do this in a single codebase. The current approach is to have two codebases (unittest2 and unittest2py3k). The reason for this is that it's rather easier to generate a Python 3 backport by applying a few patches than it is to generate the Python 2 version - so a Python 3 backport can be much simpler. It makes life harder for projects that use unittest2 though as which project they need as test runner depends on whether they are being run on Python 2 or Python 3 - so a single codebase (or single project anyway) would be better.
All the best,
> Matt McClure
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing
More information about the Python-Dev