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.

Author rbcollins
Recipients docs@python, matrixise, r.david.murray, rbcollins, torsava, zopieux
Date 2016-09-12.00:15:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1473639326.1.0.485272951473.issue25573@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2016-09-12 00:15:27rbcollinssetrecipients: + rbcollins, r.david.murray, docs@python, matrixise, zopieux, torsava
2016-09-12 00:15:26rbcollinssetmessageid: <1473639326.1.0.485272951473.issue25573@psf.upfronthosting.co.za>
2016-09-12 00:15:26rbcollinslinkissue25573 messages
2016-09-12 00:15:25rbcollinscreate