[Python-bugs-list] [ python-Bugs-451309 ] don't store traceback objects

[noreply@sourceforge.net]

Bugs item #451309, was opened at 2001-08-15 13:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451309&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Jeremy Hylton (jhylton)
>Assigned to: Jeremy Hylton (jhylton)
Summary: don't store traceback objects

Initial Comment:
A TestResult object stores the exceptions raised when
tests fail.  The only use of these stored tracebacks,
it seems, is to print a stack trace when the test run's
report is generated.

The traceback objects, however, keep pointers to a bunch
of objects that might otherwise be garbage collected. 
I ran into this on Windows, where the traceback was
keeping a file object alive.  Because the file object
was not collected, my tearDown() method could not
remove the file.

This patch changes unittest to generate the formatted
traceback immediately, so that it does not keep
tracebacks around any longer than needed.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 11:12

Message:
Logged In: YES 
user_id=6380

Jeremy, can you propose a patch for this? Steve isn't going
to fix it without some help.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-28 08:27

Message:
Logged In: YES 
user_id=31392

We had a water-cooler conversation about this issue.  It was
observed that keeping tracebacks alive until the end of a
test suite isn't very useful, because any number of objects
on the stack may be mutated during the subsequent run of the
program.  In general, a traceback object should be handed to
the debugger right away or processed in some other way.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-16 08:38

Message:
Logged In: YES 
user_id=31392

I think this feature is more trouble than it's worth. If
a testrunner wants to capture the actual exception, it
could easily override the addError or addFailure method to 
get the traceback then.

The cost of the feature is high, particularly since it is
not used by anyone.  The effects of preserving tracebacks
can be hard to discern, and I expect when it happens it
will cause a lot of confusion.  In my case, two experienced
Python programmers, who are novices with unittest, spent
several hours trying to figure out what went wrong.

I don't think updating the docs will be particularly
helpful, because this situation is somewhat unusual and
the current behavior so surprising.


----------------------------------------------------------------------

Comment By: Steve Purcell (purcell)
Date: 2001-08-15 14:46

Message:
Logged In: YES 
user_id=21477

Hi Jeremy,

This behaviour is actually known and intentional; the 
dangers are documented as a caveat in the PyUnit docs. The 
intention was that a test runner (GUI or otherwise) could 
potentially make the traceback available for inspection 
when a test fails, to aid in debugging.

In your particular case, relying on GC to close the file 
might have caused problems with following code even if 
PyUnit didn't store the traceback.

Overall I'd prefer to keep storing the tracebacks, 
especially since they only get stored when tests fail. It 
would be worth me adding a note about GC interaction to 
the docs, though.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451309&group_id=5470