This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: don't store traceback objects
Type: Stage:
Components: Library (Lib) Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: jhylton Nosy List: gvanrossum, jhylton, purcell
Priority: high Keywords:

Created on 2001-08-15 20:36 by jhylton, last changed 2022-04-10 16:04 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
*vc-diff* jhylton, 2001-08-15 20:36
Messages (6)
msg5950 - (view) Author: Jeremy Hylton (jhylton) (Python triager) Date: 2001-08-15 20:36
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.
msg5951 - (view) Author: Steve Purcell (purcell) (Python triager) Date: 2001-08-15 21:46
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.
msg5952 - (view) Author: Jeremy Hylton (jhylton) (Python triager) Date: 2001-08-16 15:38
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.
msg5953 - (view) Author: Jeremy Hylton (jhylton) (Python triager) Date: 2001-08-28 15:27
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.
msg5954 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-09-05 18:12
Logged In: YES 
user_id=6380

Jeremy, can you propose a patch for this? Steve isn't going
to fix it without some help.
msg5955 - (view) Author: Steve Purcell (purcell) (Python triager) Date: 2001-09-06 08:27
Logged In: YES 
user_id=21477

I've made a fix now. From the CVS checkin message:

Changed TestResult to store only the text representation 
of an error.

This patch is similar to that proposed by Jeremy. The 
proposed patch altered
the interface of TestResult such that it would be passed 
the error
information as a string rather than an exc_info() tuple.

The implemented change leaves the interface untouched so 
that TestResults
are still passed the tracebacks, but stor them in 
stringified form for
later reporting.

Notes:
- Custom subclasses of TestResult written by users should 
be unaffected.
- The existing 'unittestgui.py' will still work with this 
module after the
  change.
- Support can later be added to pop into the debugger when 
an error occurs;
  this support should be added to a TestRunner rather than 
to TestCase itself,
  which this change will enable.

(Jeremy, Fred, Guido: Thanks for all the feedback)

History
Date User Action Args
2022-04-10 16:04:19adminsetgithub: 34972
2001-08-15 20:36:16jhyltoncreate