[TIP] Annotated tracebacks

Chris Jerdonek chris.jerdonek at gmail.com
Sun Oct 19 16:41:14 PDT 2014


On Sun, Oct 19, 2014 at 4:29 PM, Robert Collins
<robertc at robertcollins.net> wrote:
> On 20 October 2014 12:10, Chris Jerdonek <chris.jerdonek at gmail.com> wrote:
>> On Sat, Oct 18, 2014 at 2:52 AM, Robert Collins
>> <robertc at robertcollins.net> wrote:
>>> testtools just had this bug opened on it:
>>>
>>> https://github.com/testing-cabal/testtools/issues/111
>>>
>>> Which has a few contributing issues but one in particular is that
>>> simple tracebacks don't give you the value of variables in parameters,
>>> nor of local variables in the trace.
>>>
>>> I'm aware of the implementation details that can make showing those
>>> values fraught (since __str__ and __repr__ can execute arbitrary
>>> code), but I thought I'd do a straw poll here and see who supports the
>>> idea of the traceback module itself offering to format such things
>>> (e.g. via a locals=False parameter to format_list and friends), which
>>> testtools could then backport to older pythons, and use itself to do
>>> this.
>>
>> A lot of times, it's the value of variables in frames other than the
>> final frame that are needed to troubleshoot an issue.  Is the proposal
>> only to address variables in the final frame?  It seems like if
>> something will be done in the stdlib and the enhancement is limited to
>> the final frame, then the proposed API should be chosen so that it
>> wouldn't make it harder to expand the API later on to allow
>> information about intermediate frames.
>
> All frames (that aren't hidden by unittest etc) would be processed the
> same way IMO.

Okay, great.  The only other API issue that immediately comes to mind
for me is the handling of values whose representation has many
characters.  Normally, this is handled by choosing an arbitrary length
and then truncating out some portion (e.g. the middle portion).
unittest does this, for example.  In certain cases, I've wished that
the truncation would show just a few more characters beyond the
arbitrary limit.  How do you propose handling that?  If the API
doesn't allow showing more characters, it can be frustrating because
the initial limit was arbitrary to begin with.

--Chris


>
> -Rob
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud



More information about the testing-in-python mailing list