Tim> On occasion I've happily used this kind of scheme for runtime debugging
Tim> code, inspired by the EYE language but adaptable with more or less pain
Tim> to any language:
I don't feel that there is any real need for this sort of debugging
support, but I would not oppose its introduction so long as it does
not impose a performance or memory penalty on a program that does not
use it.
But... one area where I feel that python could use some debugging help
is in the C code. The current exception mechanism of setting an error
flag and returing NULL or -1 is fine until you have to find the line
of C code that raised the exception. Since the error is not reported
until the stack is completely unwound you have to poke around the code
and really think about where it could have come from. I find that
this happens quite a bit to me when I am writting a new module or
object.
A solution to this would be to allow any C routine to augment the
exception with its file name, line number, and function name whenever
it propagates the exeception to its caller. Given a routine,
err_addtrace() say, which pushes this information onto a traceback
stack, a macro could be defined to call this function or expand to
nothing when this sort of debugging is not desired.
#ifdef DEBUG
#define ERR_ADDTRACE(name) err_addtrace(name, __FILE__, __LINE__)
#else
#define ERR_ADDTRACE(name)
#endif
The information could then be printed along with the regular
traceback. There should be a command line option or environment
variable to control whether this information is printed since it is
really only useful to implementors not users.
______ ______
\_\_\_\ /#/#/#/
\_\_\_\ ______
\_\_\_V#/#/#/ Donald Beaudry don@vicorp.com
\_\_/#/#/#/ V. I. Corporation uunet!vicorp!don
\_/#/#/#/ 47 Pleasant Street PHONE: (413) 586-4144
V#/#/#/ Northampton, MA 01060 FAX: (413) 586-3805