Message 234740 - Python tracker

➜

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.

In-reply-to
Author	ncoghlan
Recipients	adaptivelogic, eric.snow, gvanrossum, ncoghlan, pitrou, rbcollins, rhettinger, vstinner, yselivanov
Date	2015年01月26日.13:12:20
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1422277940.61.0.0937084839782.issue17911@psf.upfronthosting.co.za>

Content
I put some detailed comments in the review, but my main large scale concern is with the "traceback.Frame" name. Making "frame object" an ambiguous phrase seems like a bad idea to me, so I've suggested making it "FrameSummary" (or "FrameInfo", but on reflection I prefer the more explicit term). That would then suggest also making it "traceback.StackSummary" for consistency. I think having the top level API be an iterable would be OK, but may be a little surprising. Is there a major advantage to avoiding building the whole traceback in memory?

Content

I put some detailed comments in the review, but my main large scale concern is with the "traceback.Frame" name. Making "frame object" an ambiguous phrase seems like a bad idea to me, so I've suggested making it "FrameSummary" (or "FrameInfo", but on reflection I prefer the more explicit term). That would then suggest also making it "traceback.StackSummary" for consistency.
I think having the top level API be an iterable would be OK, but may be a little surprising. Is there a major advantage to avoiding building the whole traceback in memory?

History
Date	User	Action	Args
2015年01月26日 13:12:20	ncoghlan	set	recipients: + ncoghlan, gvanrossum, rhettinger, pitrou, vstinner, rbcollins, eric.snow, yselivanov, adaptivelogic
2015年01月26日 13:12:20	ncoghlan	set	messageid: <1422277940.61.0.0937084839782.issue17911@psf.upfronthosting.co.za>
2015年01月26日 13:12:20	ncoghlan	link	issue17911 messages
2015年01月26日 13:12:20	ncoghlan	create

homepage