Author adaptivelogic
Recipients adaptivelogic, gvanrossum, ncoghlan, pitrou
Date 2013-07-18.13:35:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1374154510.52.0.396789001745.issue17911@psf.upfronthosting.co.za>
In-reply-to
Content
I was trying to stay with the established pattern of the existing methods. There are two unrelated issues to solve here - deferring linecache access, and the extract_exception functionality.

When it comes to deferral, we could wrap each line in a different class than tuple, but this constitutes a public API change (and this is a *very* widely used library). Even changing to a namedtuple would cause a lot of grief, since we'd break lots of doctests, and subclassing tuple is a lot of effort for little benefit. If we only do it for the deferred usage, it would "only" be inconsistent. I suppose we could have a completely separate way of doing things for ExceptionSummary, but again, inconsistent, and I think if one extract_xxx method provides the functionality, users would expect it to be available in the others.

For ExceptionSummary, the same summary instance is used more than once if you have a cause set, so object creation had to be separated from the graph population. Either this is done in a constructor function or we would need some obscure tricks with the class kwargs. This way, there's a separation of concerns - the class wraps *one* exception, and the function creates a bunch and links them together as needed.
History
Date User Action Args
2013-07-18 13:35:10adaptivelogicsetrecipients: + adaptivelogic, gvanrossum, ncoghlan, pitrou
2013-07-18 13:35:10adaptivelogicsetmessageid: <1374154510.52.0.396789001745.issue17911@psf.upfronthosting.co.za>
2013-07-18 13:35:10adaptivelogiclinkissue17911 messages
2013-07-18 13:35:10adaptivelogiccreate