Issue 1654974: Binding annotations in tracebacks. (original) (raw)
Created on 2007-02-08 09:46 by nejucomo, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Messages (7)
Author: Nefarious CodeMonkey, Jr. (nejucomo)
Date: 2007-02-08 09:46
The attached module provides a suitable replacement for sys.excepthook to handle uncaught exceptions.
The output is the same, except after each source line shown, a list of relevant bindings is shown.
Here's a quick example from the tail end of a test:
File "./test-exprann.py", line 16, in f assert c == 12 # With bindings: # c = 42 AssertionError
The bindings shown are the intersection of the code object "co_names" and the non-keyword name tokens in the parsed source line. The goal is to only show bindings relevant to the exception.
I hope the utility of this is self-evident to any programmer. I tried testing it with crazy expressions containing nonfree bindings (such as lambda's and list comprehensions), so I think it behaves well in most circumstances.
The performance might be bad (it parses each line in the backtrace), but I figure it is worth it for uncaught exceptions.
Let me know if you find this tool useful.
Thanks, Nejucomo
Author: Nefarious CodeMonkey, Jr. (nejucomo)
Date: 2007-02-08 09:50
BTW, I only tested this on python 2.4.
Because it examines the parse tree (very simply), it may not work if the AST format changes. The only parsing it does is search for all NAME tokens which are not keywords, so I assumed this was stable across releases.
Author: Nefarious CodeMonkey, Jr. (nejucomo)
Date: 2007-02-12 19:00
I've simplified and modularized the design of this tool. Included is a patch against the 2.6 svn head which adds a module to the stdlib called bindann (for "binding annotation"), and then modifies the traceback module to use it. It also includes a demo script which compares classic and annotated exception tracebacks.
The interface to traceback is backwards compatible (it introduces optional arguments defaulting to pre-patch behavior).
bindann is much simpler than the previous annex file, because it doesn't try parsing, only tokenizing the source line, to look for name references. Thus it succeeds where annex would fail (for example if the head of a for-loop causes an uncaught exception, the source line will only be the head which is not a complete/parsable expression).
Here's the output of the demo:
$ ./Demo/newfeatures/demo-bindann.py This demonstrates binding-annoted exception tracebacks. Consider the following function: def f(c): for char in c + " hello": print 'The string contains "%s".' % (char,)
-With standard tracebacks, calling f(42) gives: Traceback (most recent call last): File "./Demo/newfeatures/demo-bindann.py", line 17, in main f(42) File "./Demo/newfeatures/demo-bindann.py", line 28, in f for char in c + " hello": TypeError: unsupported operand type(s) for +: 'int' and 'str'
-And now with annotated exceptions: Traceback (most recent call last): File "./Demo/newfeatures/demo-bindann.py", line 33, in # With bindings: # main = <function main at 0x300fa870> # Source: main() File "./Demo/newfeatures/demo-bindann.py", line 24, in main # With bindings: # f = <function f at 0x300fa8b0> # Source: f(42) File "./Demo/newfeatures/demo-bindann.py", line 28, in f # With bindings: c = 42 # char = # Source: for char in c + " hello": TypeError: unsupported operand type(s) for +: 'int' and 'str'
File Added: bindann-patch.1
Author: Nefarious CodeMonkey, Jr. (nejucomo)
Date: 2007-02-21 21:26
This feature has already been present in the stdlib for awhile, hidden in the cgitb module. Enable it like this:
import cgitb cgitb.enable(format="text")
I was not aware of this, assuming cgitb just formatted typical tracebacks into html. Perhaps a better design of traceback reporting in general is called for?
Author: Collin Winter (collinwinter) * 
Date: 2007-03-06 00:18
You should bring this up on the python-dev list (http://mail.python.org/mailman/listinfo/python-dev).
Author: Georg Brandl (georg.brandl) *
Date: 2007-03-13 08:01
Definitely. Adding a new stdlib module should go through a python-dev discussion.
Author: Terry J. Reedy (terry.reedy) *
Date: 2010-08-09 03:51
Nejucomo, do you have any interest in pursuing this or should be close it?
History
Date
User
Action
Args
2022-04-11 14:56:22
admin
set
github: 44560
2010-11-12 04:54:45
terry.reedy
set
status: pending -> closed
resolution: out of date
2010-08-09 03:51:34
terry.reedy
set
status: open -> pending
versions: + Python 3.2, - Python 3.1, Python 2.7
nosy: + terry.reedy
messages: +
2009-03-30 21:24:43
ajaksu2
set
stage: test needed
type: enhancement
versions: + Python 3.1, Python 2.7
2007-02-08 09:46:01
nejucomo
create