Re: [Twisted-Python] Trial __del__ behavior change - intentional?
On 12:58 am, slamb@slamb.org wrote:
It appears I can't use reference handling to clean up resources within a trial - the output code apparently keeps a reference to the stack trace or something until after it's done. That's too late for me - this resource is essentially a mutex, so if I have more than one TestCase in a single trial run, my tests don't work.
I can't speak to the intentionality of that particular change, but there are many cases where code (not necessarily trial) will do something like this temporarily. You should always treat __del__ as slightly non-deterministic unless you have a very tightly controlled test _specifically_ for your __del__ and it includes a gc.collect(). Do startup / cleanup with the 'setUp' and 'tearDown' TestCase methods. Don't depend on garbage collection: this goes for both your application and your test code. Implicitly depending on the garbage collector's behavior will very likely make your program break under the debugger, but not under normal operation (or vice versa).
glyph@divmod.com wrote:
On 12:58 am, slamb@slamb.org wrote:
It appears I can't use reference handling to clean up resources within a trial - the output code apparently keeps a reference to the stack trace or something until after it's done. That's too late for me - this resource is essentially a mutex, so if I have more than one TestCase in a single trial run, my tests don't work.
I can't speak to the intentionality of that particular change, but there are many cases where code (not necessarily trial) will do something like this temporarily. You should always treat __del__ as slightly non-deterministic unless you have a very tightly controlled test _specifically_ for your __del__ and it includes a gc.collect().
Ugh. No, under those restrictions, I'll avoid it entirely. Looks like I need more tearDown() stuff and a few finally clauses, Java-style.
Do startup / cleanup with the 'setUp' and 'tearDown' TestCase methods. Don't depend on garbage collection: this goes for both your application and your test code. Implicitly depending on the garbage collector's behavior will very likely make your program break under the debugger, but not under normal operation (or vice versa).
Is this documented somewhere? I'm not sure where the logical place is, but I'm used to CPython code that generally avoids circular references, so this strikes me as unusual - I've never had a reason to call gc.collect(), and I've rarely even noticed that Python *has* a garbage collector. Including your statement in the documentation might save some pain. Thanks for your help. Warm regards, Scott -- Scott Lamb <http://www.slamb.org/>
participants (2)
-
glyph＠divmod.com -
Scott Lamb