[New-bugs-announce] [issue17911] Extracting tracebacks does too much work

Guido van Rossum report at bugs.python.org
Sun May 5 23:31:26 CEST 2013


New submission from Guido van Rossum:

For Tulip I may have to extract tracebacks and store the extracted data, in order to avoid cycles created by the frames referenced in the traceback.  I'll be extracting the traceback every time an exception is raised, and in most cases I won't be using the extracted info, because usually the exception is caught (or logged) by user code.  But it's very important to ensure that if the user code doesn't catch or log it, I can log a traceback, and I won't know that this is the case until a destructor is called, which may be quite a bit later.  (Reference: http://code.google.com/p/tulip/source/browse/tulip/futures.py#38)

Unfortunately it looks like the public APIs do a lot more work than needed.  Ideally, there'd be something similar to _extract_tb_or_stack_iter() that doesn't call linecache.getline() -- it should just return triples of (filename, lineno, functionname), and enough structure to tell apart the __cause__, __context__, and __traceback__ (the first two possibly repeated).  Given this info it would be simple enough to format and log the actual traceback, and storing just this would take less space and time than computing the lines of the fully-formatted traceback.

----------
components: Library (Lib)
messages: 188467
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Extracting tracebacks does too much work
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17911>
_______________________________________


More information about the New-bugs-announce mailing list