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.

Author gvanrossum
Recipients akuchling, benjamin.peterson, gvanrossum
Date 2013-10-02.17:03:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1380733381.79.0.0175162036016.issue19146@psf.upfronthosting.co.za>
In-reply-to
Content
The traceback module is driving me nuts.  It has some handy helpers to extract info about a traceback or a full stack without formatting them, but (a) these are _internal, and (b) they don't return the frame object as part of the information, so code that wants to do additional stuff (e.g. print the values of local variables) cannot use them. (I guess in a sense the two problems cancel each other out. :-)

Here's a proposed fix.  (I know it is lacking tests.)

It adds extract_tb_ex() and extract_stack_ex() functions that return a list of 5-tuples filename, line number, function name, text, frame).

I'm also reworking the lowest-level internal function, _extract_tb_or_stack_iter(), to take an iterator instead of a starting point and a function to get the info and the next starting point.  The old design feels unpythonic to me -- the task at hand so clearly feels like it should wrap an iterator!

Finally, I'm adding some important info to a few docstrings: when the limit clips the number of frames, you get the *oldest* frames from a traceback, but the *newest* frames from a stack. That makes sense when you think about it, but I still think it's worth mentioning.

Feedback?
History
Date User Action Args
2013-10-02 17:03:01gvanrossumsetrecipients: + gvanrossum, akuchling, benjamin.peterson
2013-10-02 17:03:01gvanrossumsetmessageid: <1380733381.79.0.0175162036016.issue19146@psf.upfronthosting.co.za>
2013-10-02 17:03:01gvanrossumlinkissue19146 messages
2013-10-02 17:03:01gvanrossumcreate