[issue26502] traceback.extract_tb breaks compatibility by returning FrameSummary
![](https://secure.gravatar.com/avatar/fa0f7819f1825f596b384c19aa7dcf33.jpg?s=120&d=mm&r=g)
New submission from Petr Viktorin: According to the docs [0], traceback.extract_tb should return 4-tuples (filename, line number, function name, text). [0] https://docs.python.org/3/library/traceback.html#traceback.extract_tb 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. ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 261296 nosy: docs@python, encukou priority: normal severity: normal status: open title: traceback.extract_tb breaks compatibility by returning FrameSummary versions: Python 3.5, Python 3.6 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue26502> _______________________________________
![](https://secure.gravatar.com/avatar/fa0f7819f1825f596b384c19aa7dcf33.jpg?s=120&d=mm&r=g)
Changes by STINNER Victor <victor.stinner@gmail.com>: ---------- nosy: +rbcollins _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue26502> _______________________________________
![](https://secure.gravatar.com/avatar/fa0f7819f1825f596b384c19aa7dcf33.jpg?s=120&d=mm&r=g)
Berker Peksag added the comment: This is basically a duplicate of issue 25573. We need to add the examples in traceback module documentation to test_traceback.py.
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. ---------- nosy: +berker.peksag resolution: -> duplicate stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue26502> _______________________________________
![](https://secure.gravatar.com/avatar/fa0f7819f1825f596b384c19aa7dcf33.jpg?s=120&d=mm&r=g)
R. David Murray added the comment: 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. ---------- nosy: +r.david.murray resolution: duplicate -> stage: resolved -> needs patch status: closed -> open _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue26502> _______________________________________
![](https://secure.gravatar.com/avatar/fa0f7819f1825f596b384c19aa7dcf33.jpg?s=120&d=mm&r=g)
Change by Berker Peksag <berker.peksag@gmail.com>: ---------- keywords: +patch pull_requests: +8137 stage: needs patch -> patch review _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue26502> _______________________________________
![](https://secure.gravatar.com/avatar/fa0f7819f1825f596b384c19aa7dcf33.jpg?s=120&d=mm&r=g)
Petr Viktorin <encukou@gmail.com> added the comment: New changeset 9797b7ae4496627836c55333765e10201a9840e3 by Petr Viktorin (Berker Peksag) in branch 'master': bpo-26502: Implement FrameSummary.__len__() (GH-8632) https://github.com/python/cpython/commit/9797b7ae4496627836c55333765e10201a9... ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue26502> _______________________________________
![](https://secure.gravatar.com/avatar/fa0f7819f1825f596b384c19aa7dcf33.jpg?s=120&d=mm&r=g)
Berker Peksag <berker.peksag@gmail.com> added the comment: Thanks for merging this, Petr. What do you think about backporting to 3.7? ---------- components: -Documentation versions: +Python 3.8 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue26502> _______________________________________
![](https://secure.gravatar.com/avatar/fa0f7819f1825f596b384c19aa7dcf33.jpg?s=120&d=mm&r=g)
Petr Viktorin <encukou@gmail.com> added the comment: 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. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue26502> _______________________________________
![](https://secure.gravatar.com/avatar/fa0f7819f1825f596b384c19aa7dcf33.jpg?s=120&d=mm&r=g)
Berker Peksag <berker.peksag@gmail.com> added the comment: Ok, let's close this issue then. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue26502> _______________________________________
participants (4)
-
Berker Peksag
-
Petr Viktorin
-
R. David Murray
-
STINNER Victor