Title: traceback.extract_tb breaks compatibility by returning FrameSummary
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.8
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: docs@python Nosy List: berker.peksag, docs@python, petr.viktorin, r.david.murray, rbcollins
Priority: normal Keywords: patch

Created on 2016-03-07 11:15 by petr.viktorin, last changed 2018-09-11 17:54 by berker.peksag. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 8632 merged berker.peksag, 2018-08-02 17:46
Messages (7)
msg261296 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2016-03-07 11:15
According to the docs [0], traceback.extract_tb should return 4-tuples (filename, line number, function name, text).


Instead, since Python 3.5, it returns FrameSummary objects, which are not tuples, nor tuple subclasses, nor even sequences. (This broke some code in the wild that called len() on FrameSummary.)

Issue 25111 pointed out another tuple incompatibility, which was fixed. Should __len__ be added as well? Or the whole Sequence ABC?

I can provide a patch when those questions are answered.
msg261357 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2016-03-08 12:52
This is basically a duplicate of issue 25573. We need to add the examples in traceback module documentation to

> Should __len__ be added as well?

IMO, the new FrameSummary API (and its friends) shouldn't change the return value of the existing traceback functions like extract_tb() so I'd say yes.
msg275356 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-09-09 17:35
I disagree that this is a duplicate.  The question here is, should we add __len__?  Since a FrameSummary object can be "cast into a tuple" and has a known len, I would say the answer is definitely yes.
msg324937 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2018-09-10 17:02
New changeset 9797b7ae4496627836c55333765e10201a9840e3 by Petr Viktorin (Berker Peksag) in branch 'master':
bpo-26502: Implement FrameSummary.__len__() (GH-8632)
msg325036 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2018-09-11 17:33
Thanks for merging this, Petr. What do you think about backporting to 3.7?
msg325038 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2018-09-11 17:49
I don't think I have a good enough feel for what should, generally, go to 3.7. So take my opinion with a grain of salt.

But honestly, I don't think the issue is important enough -- I've only seen one codebase affected by it, which wasn't hard to fix.
msg325040 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2018-09-11 17:54
Ok, let's close this issue then.
Date User Action Args
2018-09-11 17:54:10berker.peksagsetstatus: open -> closed
versions: - Python 3.5, Python 3.6
messages: + msg325040

resolution: fixed
stage: patch review -> resolved
2018-09-11 17:49:10petr.viktorinsetmessages: + msg325038
2018-09-11 17:33:43berker.peksagsetmessages: + msg325036
components: - Documentation
versions: + Python 3.8
2018-09-10 17:02:36petr.viktorinsetmessages: + msg324937
2018-08-02 17:46:45berker.peksagsetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request8137
2016-09-09 17:35:14r.david.murraysetstatus: closed -> open

nosy: + r.david.murray
messages: + msg275356

resolution: duplicate -> (no value)
stage: resolved -> needs patch
2016-03-08 12:52:51berker.peksagsetstatus: open -> closed

type: behavior

nosy: + berker.peksag
messages: + msg261357
resolution: duplicate
stage: resolved
2016-03-08 12:36:47vstinnersetnosy: + rbcollins
2016-03-07 11:15:48petr.viktorincreate