[issue25573] traceback documentation example is lying about FrameSummary repr()
New submission from Alexandre Macabies: https://docs.python.org/3.5/library/traceback.html#traceback-examples See second code sample and its sample output. According to the docs, the call: print(repr(traceback.extract_tb(exc_traceback))) is supposed to print something that looks like an array with only strings; that is what the doc sample output states: [('<doctest...>', 10, '<module>', 'lumberjack()'), But actually, in 3.5+, this call outputs the repr() of a list of FrameSummary instances that do not go further in repr()esenting their state: [<FrameSummary file <ipython-input-61-3e63d7daea82>, line 10 in <module>>, By looking at the docs I thought I was able to get a nice string representation of a FrameSummary. I actually have to format it myself. It should be reflected in the doc sample output. ---------- assignee: docs@python components: Documentation messages: 254224 nosy: Alexandre Macabies, docs@python priority: normal severity: normal status: open title: traceback documentation example is lying about FrameSummary repr() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue25573> _______________________________________
R. David Murray added the comment: IMO, that is neither a lie nor a doc bug, it is a bug in the new traceback features that were added in 3.5. ---------- assignee: docs@python -> keywords: +3.5regression nosy: +r.david.murray, rbcollins stage: -> needs patch title: traceback documentation example is lying about FrameSummary repr() -> FrameSummary repr() does not support previously working uses of repr in traceback module _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue25573> _______________________________________
Stéphane Wirtel added the comment: Could you check with Python 3.4 ? ---------- nosy: +matrixise _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue25573> _______________________________________
Stéphane Wirtel added the comment: Oops, sorry, ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue25573> _______________________________________
Tomas Orsava added the comment: This problem has already been addressed in issue 27208, and it was fixed by updating the documentation to reflect the new repr(). Therefore, I believe this issue can be closed. ---------- nosy: +torsava _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue25573> _______________________________________
R. David Murray added the comment: Is there a reason the fourth element of the tuple is not included in the FrameSummary repr? Otherwise I agree that this could be closed. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue25573> _______________________________________
R. David Murray added the comment: Ah, I see there is. It is read lazily. It is an interesting question whether it should be read when the repr is printed...let's say no until/unless someone comes up with a good reason why it would be worthwhile. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue25573> _______________________________________
R. David Murray added the comment: I take it back. Since tuple(framesummary) produces all four elements, I think the repr should too. Likewise, in the __len__ issue I think it should always report 4. Let see if other devs agree. ---------- resolution: fixed -> stage: resolved -> needs patch status: closed -> open _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue25573> _______________________________________
Robert Collins added the comment: So I think its fine to have a __len__ reporting 4. tuple(..) works via the iter() call, but thats really just a thunk to keep existing code working, and so __len__ for the same reason makes sense. On the documentation issue, yes, updating the docs is appropriate. Having the repr produce all the elements would be ok, the reason it is lazy is to avoid high costs for transient FrameSummary when its created and discarded shortly after. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue25573> _______________________________________
Change by Berker Peksag <berker.peksag@gmail.com>: ---------- nosy: +berker.peksag _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue25573> _______________________________________
Irit Katriel <iritkatriel@yahoo.com> added the comment: I think the fourth element (the code line) was omitted from repr because it is not one of the constructor args for FrameSummary (it is derived from them), so it's redundant in terms of describing this instance. ---------- nosy: +iritkatriel versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue25573> _______________________________________
Change by Irit Katriel <iritkatriel@yahoo.com>: ---------- keywords: +patch pull_requests: +22551 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/23687 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue25573> _______________________________________
Change by Irit Katriel <iritkatriel@yahoo.com>: ---------- pull_requests: -22551 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue25573> _______________________________________
Change by Irit Katriel <iritkatriel@yahoo.com>: ---------- pull_requests: +22553 pull_request: https://github.com/python/cpython/pull/23687 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue25573> _______________________________________
Change by Irit Katriel <iritkatriel@yahoo.com>: ---------- pull_requests: +22554 pull_request: https://github.com/python/cpython/pull/23688 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue25573> _______________________________________
Change by Irit Katriel <iritkatriel@yahoo.com>: ---------- pull_requests: -22553 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue25573> _______________________________________
Change by Irit Katriel <iritkatriel@yahoo.com>: ---------- pull_requests: -22554 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue25573> _______________________________________
participants (7)
-
Alexandre Macabies -
Berker Peksag
-
Irit Katriel
-
R. David Murray
-
Robert Collins
-
Stéphane Wirtel
-
Tomas Orsava