On Nov 22 2007, 4:31 pm, [EMAIL PROTECTED] (John J. Lee) wrote: > [EMAIL PROTECTED] writes: > > I am trying to use thetracemodulewith the --count flag to test for > > statement coverage in my doctests. Thetracecoverage listing is very > > weird, marking many statements as unexecuted which were clearly executed > > during the run (I can see their output on the screen). Is this some known > > interaction between thetraceanddoctestmodules? > > Yes: > > http://python-nose.googlecode.com/svn/trunk/nose/plugins/doctests.py > > http://svn.zope.org/Zope3/trunk/src/zope/testing/doctest.py?rev=28679... > > John
Interesting. Is this problem caused or ascerbated by the fact that sys.settrace() is this sort of global? I've been looking at redoing pdb from scratch, from the bottom up. As Obama might say in a different context, "line by line". I sort of don't like the global-ness of pdb, or for that matter the sys.settrace's trace hook. So as a start, I wrote a "tracer" module (http://code.google.com/p/pytracer/ and on Pypi) which just a wrapper around the global trace hook to allow different applications to register trace events and not clobber one-another. Possibly in an Ideal world, Python would itself have done the trace hook chaining. (I believe that the case in Ruby ;-) But Python 2.6 does now allow you *query* to find out if a trace hook has been installed, chaining so it is now possible, even though tracer doesn't use the 2.6 sy.gettrace () to allow it chain outside of routines that use it directly. But as I wonder if this kind of problem would have been avoided if there had been a wrapper to allow settrace chaining? (And if that is s -- unlikely as it is to happen -- various applications like tracer, doctest and pdb could be rewritten to use tracer.) -- http://mail.python.org/mailman/listinfo/python-list
