trace module and doctest

[R. Bernstein]

On Nov 22 2007, 4:31 pm, j... at pobox.com (John J. Lee) wrote:
> s... at pobox.com 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.)