[Python-ideas] Compressing excepthook output

[Nick Coghlan]

On 16 September 2013 10:07, Steven D'Aprano <steve at pearwood.info> wrote:
> On Mon, Sep 16, 2013 at 01:39:46AM +0200, אלעזר wrote:
>> I suggest adding an excepthook that prints out a compressed version of the
>> stack trace. The new excepthook should be the default at least for
>> interactive mode.
> [...]
>> I have tried to implement an alternative for sys.excepthook (see below),
>> which compresses the last simple cycle in the call graph. Turns out it's
>> not trivial, since the traceback object is not well documented (and maybe
>> it shouldn't be, as it is an implementation detail) so it's non trivial (if
>> at all possible) to change the trace list in an existing traceback. I don't
>> think it is reasonable to just send anyone interested in such a feature to
>> implement it themselves - especially given that newcomers ate its main
>> target - and even if we do, there is no simple way to make it a default.
>
> I like where this is going. Tracebacks for recursive function calls
> are extremely noisy, with the extra lines rarely giving any useful
> information.
>
> Have a look at the cgitb module in the standard library.
>
> I think you should start off by cleaning up your traceback handler to be
> less "ugly and fragile" (your words), if possible, and then consider
> publishing it on ActiveState's website as a Python recipe. That would be
> the first step in gathering user feedback and experience in the real
> world, and if it turns out to be useful in practice, at a later
> date we can look at adding it to the standard library.
>
> http://code.activestate.com/recipes/

Another couple of potentially useful pointers:

- the traceback.py source is a good place to get more details on how
traceback objects work
(http://hg.python.org/cpython/file/default/Lib/traceback.py)

- you may want to try out the updated traceback extraction API
proposed in http://bugs.python.org/issue17911 and see if that cleans
up your code. If it helps, that would be good validation of the
proposed new API, if it doesn't, it may provide hints for further
improvement.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia