Message193296
> 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.
YMMV, but I think we should go for inconsistency here. The other APIs
in the traceback module are low-level and clearly limited by the type
of objects they return.
This feature request is a good opportunity to design something a little
more future-proof. I'd love to know what other developers/contributors
think here. |
|
Date |
User |
Action |
Args |
2013-07-18 13:45:23 | pitrou | set | recipients:
+ pitrou, gvanrossum, ncoghlan, adaptivelogic |
2013-07-18 13:45:23 | pitrou | link | issue17911 messages |
2013-07-18 13:45:23 | pitrou | create | |
|