[Twisted-Python] Trial __del__ behavior change - intentional?

[Scott Lamb]

glyph at divmod.com wrote:
> On 12:58 am, slamb at 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/>