1. Holger Krekel
  2. py-trunk
  3. Issues
Issue #1 open

Feature Request: condensed tracebacks for less interesting modules

Dusty Phillips
created an issue

I'd like the ability to hide or condense traceback output from 'uninteresting' modules.

A specific use case I have is running some tests using urllib2. When there is an HTTP error, py.test gives me a traceback of a bunch of urllib2 internals, where all I really need is the line in my code that called urllib2.urlopen -- I don't need the code samples for each function in urllib2 that elevated the exception.

The sticky point is how to define 'uninteresting'. Some options include:

  • Not displaying code samples for standard library code, or for code that isn't in my working directory.
  • Configuration options to disable certain modules as they come up. Deep tracebacks as found in urllib2 are not that common.
  • Call something like py.test.no_codesample('urllib2') inside test functions to disable the code samples/traceback

Here's a simple example test to trigger a longish traceback:

{{{

!python

import urllib2

def test_traceback(): stream = urllib2.urlopen('http://example.com/file/not/exist/404.html') content = stream.read()

}}}

Comments (5)

  1. Holger Krekel repo owner
    • changed version to 1.1

    Hello Dusty,

    thanks for the submission and suggestions. I see the need of condensing tracebacks. As you say there are various strategies. I think i'd like to provide an extensible mechanism by extending the "--tb" command line option (or providing a new "--tbopt" option). One could e.g. provide "testonly" or "no-std" (or both) to modify traceback printing. Do you think it's neccessarry/sensible to allow to set this per-function, i.e. in the actual testing code as opposed to from the command line or per conftest-options? I foresee GUI-runners or HTML-reports that would anyway ignore this as they had different ways to present tracebacks, i guess.

    cheers, holger

  2. Anonymous

    Hi Holger,

    I can't come up with a use-case for per-test traceback configuration. That would imply that you know in advance which tests have long tracebacks. My typical usage is to run my test suite expecting everything to pass (because I never introduce bugs ;-). Sometimes I get "OMG FAIL", at which point I typically nerun with --exitfirst and/or --looponfail. At this point I'd also add the --tb[opt] option if the original failure showed too much source code.

    One way to solve this problem could be to turn the reporting plugin into a series of chained 'filters' (aka pipes). If you could stack and/or mix and match reporting filters that add or remove traceback information, code snippets, colouring, htmlified output, and so on, it would provide a lot of flexibility... possibly too much. ;-)

    Thanks for looking into this, Dusty

  3. Holger Krekel repo owner
    • changed status to open

    Hi dusty,

    ok, good. i think we agree on the --tb[opt] strategy.

    implementation wise, terminal-reporting and traceback-formatting are separated, currently traceback formatting happens via py/code/excinfo.py, whereas terminal-reporting merely calls into this mechanism. I guess we could introduce a "pytest_terminal_tbprocess" hook to allow post-processing from plugins. This would also allow projects with special needs (like PyPy or other large apps) to present nicer tracebacks. Some more thinking needed, maybe.

    But that shouldn't keep from going for a simple --tb[opt] implementation. cheers, holger

  4. Log in to comment