Author pitrou
Recipients adaptivelogic, gvanrossum, ncoghlan, pitrou
Date 2013-07-18.13:45:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <594652886.4271641.1374155117213.JavaMail.root@zimbra10-e2.priv.proxad.net>
In-reply-to <1374154510.52.0.396789001745.issue17911@psf.upfronthosting.co.za>
Content
> 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.
History
Date User Action Args
2013-07-18 13:45:23pitrousetrecipients: + pitrou, gvanrossum, ncoghlan, adaptivelogic
2013-07-18 13:45:23pitroulinkissue17911 messages
2013-07-18 13:45:23pitroucreate