traceback.py contains a lot of code duplication, which makes it fragile in the face of changes (i.e. special cases) to the stack/traceback output (I am separately working on just such a change).

The attached patch refactors the code to reduce to a single function for each bit of logic, wrapped by the various existing APIs. The new helper functions are refactored as generators so as not to create unnecessary transient lists (not that stacks usually get very big anyway).

I've fully tested the replacement module, and it passes all the traceback tests in the standard suite.

How much does this overlap with #17491?

I hadn't spotted that one!

My refactor goes further (consolidates all duplicates, not just the tb ones), is implemented the way you suggested therein (print in terms of extract), and is "more efficient" in that it uses generators for all intermediate iterators. 

However, I'm happy to either attach my diff to that issue, refactor mine in terms of that one, or whatever you think is best.

The other patch author hasn't updated his patch, so this issue can just superseded the other one.

I uploaded a few review comments.

Okay. Will you upload the latest version?

Latest upload has all of the agreed markups from the review.

What's this "f_invisible" thing?

Sorry, that is an unrelated change I was experimenting with, which I accidentally forgot to take out.

Please see the new uploaded diff.

patching file Lib/traceback.py
patch: **** malformed patch at line 94: @@ -50,25 +90,7 @@

How embarrassing - I guess that'll teach me to try to doctor the diff file. :-)

I've now regenerated the diff, and re-run all the testing, etc. Apologies for the churn.

Also, this patch seems to break test_zipimport.

print_tb() wasn't passing the file argument through to print_list() - now fixed. I also verified none of the other functions had a similar bug.

It would be great to have a test for that. :)

On 20/04/2013 03:54, Benjamin Peterson wrote:
> It would be great to have a test for that. :)

I was afraid you'd say that. ;-)

I'll look at adding test cases to cover the functions not currently
covered (seems most of the print functions aren't, and all of the
'stack' functions aren't).

Could print_exception() in Lib/idlelib/run.py reuse new traceback functions?

On 20 Apr 2013, at 18:55, Serhiy Storchaka <report@bugs.python.org> wrote:
> Serhiy Storchaka added the comment:
> 
> Could print_exception() in Lib/idlelib/run.py reuse new traceback functions?

Actually, cleaning up code like that in Idle and the code module and import.c was what I was aiming to solve when I stumbled upon the duplication in traceback.py - once this patch is in, I plan to raise a separate issue with my suggestion for that clean up.

To answer your question directly, the changes I've made here don't solve the problem, no. More invasive changes are required, which is why I raised this cleanup portion of my change separately (on the assumption this change alone wouldn't be controversial, but my wider change might be).

Attached another diff, which includes new test cases to cover all functions that weren't covered before - expect print_last. I couldn't see a way of getting sys.last_* set to test that function (it seems to require an "unhandled exception"). However, the function is a simple wrapper around print_exception, and I have tested it manually in the interactive interpreter.

New changeset 84cef4f1999a by Benjamin Peterson in branch 'default':
refactor traceback.py to reduce code duplication (closes #17646)
http://hg.python.org/cpython/rev/84cef4f1999a