Antoine - I like your idea, but I think it's a separate issue. I agree with Guido that exposing some lower level non-formatting APIs in the traceback module would be helpful.

I see Guido's suggestion here as similar to the change we just made in the dis module to expose a dis.get_instructions iterator. That change makes it much easier to work with the disassembler output programmatically, whereas the module was previously too focused on displaying text with a specific format.

My current thoughts: define a "TracebackSummary" with the following fields:

    exc_type
    exc_repr
    stack_summary
    cause
    context

stack_summary would be a list of (filename, lineno, functionname) triples as Guido suggested (probably a named tuple)

cause and context would be either None or a reference to an appropriate TracebackSummary object

Basically, the summary should contain all of the information needed to create the formatted traceback output, without actually doing any formatting (aside from calling repr() on the exception)