Options

• tracer lets you specify a custom tracer object. The simplest way to create it is to extend the Tracer class and override the trace_in and trace_out methods. With a customm tracer you can do things like write the trace in any format, like HTML, JSON, XML etc, or send it over the network. The common options to the builtin Tracer classes are:

  • include_hidden if set to True, also trace functions whose name starts with _. Note, the __repr__ function will never be traced, and currently any tracing of functions starting with __ are disabled.

  • depths a dict where the keys are functions/methods and the values are integers representing the depth to which you want to trace that function/method. For example a depth of 0 means “do not trace this function at all”, even if it calls functions that are being traced. A depth of 1 will trace this function but skip all tracing until it returns. A depth of 2 will trace another level deeper. Note, the depths represent the depth of the trace output, NOT the python call stack.

Output

- module1.function1("arg1", "arg2", option=True)
|    - module1.function2("arg2")
|    |    - module1.check_thing()
|    |    -> True
|    -> "myresult"
-> "myresult"
- Class1.x(<Class1 object at 0xdeadbeef>, "arg1val", "arg2val")
|    - module2.function1("arg2val")
|    -> "foo"
|    - Class2.y(<Class2 object at 0xabcd0001>, "arg1val")
|    -> BadInputException("You can't call y with 'arg1val'!")
-> BadInputException("You can't call y with 'arg1val'!")

• Methods will show the first argument self. By default, arguments and return values are printed using repr, so if you want to see something more informative than <Class1 object at 0xdeadbeef>, you can define __repr__ on Class1 to print whatever you like (probably the values of various fields of that object).

• By default, exceptions that are raised by a function are printed as its return value, prefixed with !!!. This makes it possible to see an exception propagating down the stack.