[TIP] Annotated tracebacks
robertc at robertcollins.net
Sun Oct 19 03:07:53 PDT 2014
On 19 Oct 2014 21:38, "holger krekel" <holger at merlinux.eu> wrote:
> On Sat, Oct 18, 2014 at 22:52 +1300, Robert Collins 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.
> What do you mean with "variables in parameters"
Ideally this code:
a = 3
b = 4
would show something like:
for the frame of called.
> > 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.
> > In terms of addressing the implementation details, my thoughts today
> > are to render the traceback once in simple mode, and then once with
> > variables, and if something throws during the variable render, just
> > use the simple one.
> I am open to discuss what it takes to factor out or reimagine pytest's
> traceback code (tested against py26-py34,pypy) so it becomes useable from
> testtools. You can see it in action with:
That would be great. Ideally I think this belongs in the stdlib in the
traceback module. In a pinch testtools /could/ depend on py.test and
bring it in, but I'd like to keep deps fairly shallow and focused on
things where much of the functionality is used.
If you want I can prepare a patch to traceback based on your code, or you can.
> py.test --tb=short,long,native [--full-trace] [--showlocals] somefile.py
> If somefile.py contains:
> def test_function():
> i = 3
> assert i == 4
> While the code for the traceback code leaves things to be desired
> (i wrote parts of it 8 years ago), it is quite battle tested because
> it overtime incorporated tests and fixes for reported bugs.
> Note that the assertion expression code showing (values in expressions)
> is not strictly related to traceback manipulation and can be manipulated
> separately with "--assert=rewrite|plain|reinterp"
Yeah- the assert stuff is very distinctively py.test, and its
something I'd propose we consider separately ;)
More information about the testing-in-python