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.

Title: FrameSummary repr() does not support previously working uses of repr in traceback module
Type: Stage: patch review
Components: Documentation Versions: Python 3.10, Python 3.9, Python 3.8
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: berker.peksag, docs@python, iritkatriel, matrixise, r.david.murray, rbcollins, torsava, zopieux
Priority: normal Keywords: 3.5regression, patch

Created on 2015-11-06 21:34 by zopieux, last changed 2022-04-11 14:58 by admin.

Messages (10)
msg254224 - (view) Author: zopieux (zopieux) * Date: 2015-11-06 21:34
See second code sample and its sample output. According to the docs, the call:


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.
msg254228 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-11-06 21:43
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.
msg254230 - (view) Author: Stéphane Wirtel (matrixise) * (Python committer) Date: 2015-11-06 21:45
Could you check with Python 3.4 ?
msg254234 - (view) Author: Stéphane Wirtel (matrixise) * (Python committer) Date: 2015-11-06 22:10
Oops, sorry,
msg273931 - (view) Author: Tomas Orsava (torsava) * Date: 2016-08-30 16:27
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.
msg275355 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-09-09 17:28
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.
msg275371 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-09-09 18:22
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.
msg275375 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-09-09 18:30
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.
msg275896 - (view) Author: Robert Collins (rbcollins) * (Python committer) Date: 2016-09-12 00:15
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.
msg380334 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2020-11-04 15:58
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.
Date User Action Args
2022-04-11 14:58:23adminsetgithub: 69759
2020-12-08 01:52:34iritkatrielsetpull_requests: - pull_request22554
2020-12-08 01:43:36iritkatrielsetpull_requests: - pull_request22553
2020-12-08 01:43:14iritkatrielsetpull_requests: + pull_request22554
2020-12-08 01:36:15iritkatrielsetpull_requests: + pull_request22553
2020-12-08 01:34:57iritkatrielsetpull_requests: - pull_request22551
2020-12-08 01:31:16iritkatrielsetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request22551
2020-11-04 15:58:18iritkatrielsetnosy: + iritkatriel

messages: + msg380334
versions: + Python 3.8, Python 3.9, Python 3.10, - Python 3.5, Python 3.6
2018-08-02 17:54:06berker.peksagsetnosy: + berker.peksag
2016-09-12 00:15:26rbcollinssetmessages: + msg275896
2016-09-09 18:30:44r.david.murraysetstatus: closed -> open
resolution: fixed ->
messages: + msg275375

stage: resolved -> needs patch
2016-09-09 18:22:01r.david.murraysetstatus: open -> closed
resolution: fixed
messages: + msg275371

stage: needs patch -> resolved
2016-09-09 17:28:39r.david.murraysetmessages: + msg275355
2016-08-30 16:27:11torsavasetnosy: + torsava
messages: + msg273931
2015-11-06 22:10:52matrixisesetmessages: + msg254234
2015-11-06 21:45:41matrixisesetnosy: + matrixise
messages: + msg254230
2015-11-06 21:43:54r.david.murraysetassignee: docs@python ->
title: traceback documentation example is lying about FrameSummary repr() -> FrameSummary repr() does not support previously working uses of repr in traceback module
keywords: + 3.5regression
nosy: + r.david.murray, rbcollins

messages: + msg254228
stage: needs patch
2015-11-06 21:34:26zopieuxcreate