Does Skip's idea have any merit?
Yes, but not as a default behavior. Many people already consider the fact that tracebacks display file paths to be a potential security problem. If anything, the default traceback display should have less information, not more. (E.g., display module __name__ instead of the code's __file__).
Also note that the stdlib already has a cgitb module that does this sort of display for CGI scripts, so the technique isn't new, and cgitb provides a good example for people to create their own advanced traceback formatters with.
If there were another command line option added to Python for this, I'd personally prefer it be an option to enter the debugger when a terminal traceback is printed. Currently, I use 'python -i' so that I get an interpreter prompt, then use 'import pdb; pdb.pm()' to enter the debugger at the point where the error occurred. One can then print whatever local variables are desired, go up and down the stack, list code, and even perform calculations on the values on the stack.
About the only place I can think of where such an extremely verbose traceback would be useful and safe, is inside of unit tests. I believe that the py.test package uses traceback introspection of this kind in order to display relevant values when an assertion fails. So, it might be useful in the context of a unit test error report to get some of that information, but even there, there is a question of how much is relevant for display.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
