Message193294
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. |
|
Date |
User |
Action |
Args |
2013-07-18 13:35:10 | adaptivelogic | set | recipients:
+ adaptivelogic, gvanrossum, ncoghlan, pitrou |
2013-07-18 13:35:10 | adaptivelogic | set | messageid: <1374154510.52.0.396789001745.issue17911@psf.upfronthosting.co.za> |
2013-07-18 13:35:10 | adaptivelogic | link | issue17911 messages |
2013-07-18 13:35:10 | adaptivelogic | create | |
|