On 14/04/2011, Michael Foord <fuzzy...@voidspace.org.uk> wrote: > I'd be interested to know what is keeping the tests alive even when the > test suite isn't. As far as I know there is nothing else in unittest > that would do that.
The main cause is some handy code for collecting and filtering tests by name, which unintentionally keeps alive a list outside the TestSuite instance. There's also the problem of reference cycles involving exc_info, bound methods, and so on that make the lifetimes of test cases unpredictable. That's mostly a problem for systems with a very limited allotment of certain resources such as socket handles. However it also makes ensuring the code doesn't regress back to leaking-the-universe more complicated as tests may still survive past the pop. > It's either a general problem that unittest can fix, or it is a problem > *caused* by the bazaar test suite and should be fixed there. Bazaar does > some funky stuff copying tests to run them with different backends, so > it is possible that this is the cause of the problem (and it isn't a > general problem). The fact it's easy to accidentally keep objects alive is a general problem. If every project that writes their own little test loader risks reverting to immortal cases, that's not really progress. The Bazaar example is a warning because the intention was the same as yours, but ended up being a behaviour regression that went unnoticed by most of the developers while crippling others. And as John mentioned, the fix hasn't yet landed, mostly because the hack is good enough for me and the right thing is too complicated. Martin _______________________________________________ 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
