[zope.testing.doctest] a nasty surprise
As the community (apparently) strongly favors "doctest" over "unittest", I wrote my first test based on "zope.testing.doctest". And promptly, I was badly surprised.... In order to analyse a difficult problem, I added "from dm.pdb import zpdb; zpdb.set_trace()" in the doctest ("dm.pdb.zpdb" is my Zope aware PDB extension) -- and got a "TypeError: set_trace requires at least one argument, 0 given". Now, I know the "zpdb.set_trace()" does not want any arguments. I moved the line from the doctest code into the failing infrastructure code -- same "TypeError". I called "help(zpdb.set_trace)" and got: Help on function set_trace in module zope.testing.doctest: set_trace(self) Apparently, "doctest" has overridden "zpdb.set_trace" in an incompatible way.... I will rewrite my test as "unittest" and probably avoid in the future "zope.testing.doctest" whenever possible. -- Dieter
Dieter Maurer wrote:
As the community (apparently) strongly favors "doctest" over "unittest", I wrote my first test based on "zope.testing.doctest". And promptly, I was badly surprised....
In order to analyse a difficult problem, I added "from dm.pdb import zpdb; zpdb.set_trace()" in the doctest ("dm.pdb.zpdb" is my Zope aware PDB extension)
The standard PDB works fine. I'm sure you're extended version can be tweaked to as well. -- Benji York Senior Software Engineer Zope Corporation
Benji York wrote at 2008-4-10 11:50 -0400:
Dieter Maurer wrote:
As the community (apparently) strongly favors "doctest" over "unittest", I wrote my first test based on "zope.testing.doctest". And promptly, I was badly surprised....
In order to analyse a difficult problem, I added "from dm.pdb import zpdb; zpdb.set_trace()" in the doctest ("dm.pdb.zpdb" is my Zope aware PDB extension)
The standard PDB works fine. I'm sure you're extended version can be tweaked to as well.
Does a documentation exist how "doctest" manipulates "set_trace" and what it expects that the manipulation succeeds. Apparently, "doctest" has replaced my "set_trace" in "zpdb" by its non working implementation of "set_trace". I can understand that my "set_trace" would not have worked (as probably "sys.stdout/err" points somewhere else then usual), but I have difficulties to understand why "doctest"'s "set_trace" does not work (at all). -- Dieter
On Thu, Apr 10, 2008 at 08:46:15PM +0200, Dieter Maurer wrote:
Benji York wrote at 2008-4-10 11:50 -0400:
Dieter Maurer wrote:
As the community (apparently) strongly favors "doctest" over "unittest", I wrote my first test based on "zope.testing.doctest". And promptly, I was badly surprised....
In order to analyse a difficult problem, I added "from dm.pdb import zpdb; zpdb.set_trace()" in the doctest ("dm.pdb.zpdb" is my Zope aware PDB extension)
The standard PDB works fine. I'm sure you're extended version can be tweaked to as well.
Does a documentation exist how "doctest" manipulates "set_trace" and what it expects that the manipulation succeeds.
Documentation? Well, there are some comments in the source file... doctest monkey-patches pdb.set_trace (in an ugly way, IMHO) to restore sys.stdout, because you want the output from pdb commands like 'list' or 'print' to go to your console, and not to the doctest's actual result StringIO collector.
Apparently, "doctest" has replaced my "set_trace" in "zpdb" by its non working implementation of "set_trace".
I find it hard to believe. It's more likely that zpdb is interacting with pdb.set_trace in a way that conflicts with doctest's monkey-patch. Is the zdpb module available on the web somewhere?
I can understand that my "set_trace" would not have worked (as probably "sys.stdout/err" points somewhere else then usual), but I have difficulties to understand why "doctest"'s "set_trace" does not work (at all).
Marius Gedminas -- ...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and the Ugly). -- Matt Welsh
Marius Gedminas wrote at 2008-4-10 22:37 +0300:
... doctest monkey-patches pdb.set_trace (in an ugly way, IMHO) to restore sys.stdout, because you want the output from pdb commands like 'list' or 'print' to go to your console, and not to the doctest's actual result StringIO collector.
Apparently, "doctest" has replaced my "set_trace" in "zpdb" by its non working implementation of "set_trace".
I find it hard to believe. It's more likely that zpdb is interacting with pdb.set_trace in a way that conflicts with doctest's monkey-patch.
Is the zdpb module available on the web somewhere?
"dm.pdb" is on "PyPI". And your intuition is right. "zpdb" rebinds "pdb.set_trace" overriding the name "Pdb". Now, I also understand how the "TypeError" results: "doctest" has replaced the function "set_trace" by an instance method. Rebinding unwraps the "InstanceMethod" and operates only on the enclosed function -- the implicit instance argument is lost. -- Dieter
On Thu, 10 Apr 2008 11:50:35 -0400, Benji York wrote:
Dieter Maurer wrote:
As the community (apparently) strongly favors "doctest" over "unittest", I wrote my first test based on "zope.testing.doctest". And promptly, I was badly surprised....
In order to analyse a difficult problem, I added "from dm.pdb import zpdb; zpdb.set_trace()" in the doctest ("dm.pdb.zpdb" is my Zope aware PDB extension)
The standard PDB works fine. I'm sure you're extended version can be tweaked to as well.
I have similar issues with ipdb. - similar in sense that I cannot use it when running from doctests. ipdb is a lightweight component that enables entering ipython when "import ipdb; ipdb.set_trace()" is called. Those of you that use ipython and also develop with doctests a lot, will understand why it would be a nice to have also from doctests. In case of ipdb I had no parameters problem like Dieter encountered with zpdb, however I observed that the doctest runner needs to redirect input and output while running tests, which are specifically routed back to stdin and stdout while pdb.set_trace is entered, to enable interactivity. This is done by monkeypatching pdb if I remember well. But the same does not happen with ipdb, of course. So, my conclusion is that while doctests work well with the standard pdb, any alternate debugger must be supported explicitely (by changing the doctest code). As with ipdb, this may be the case with zpdb as well. Best wishes -- Balazs Ree
Balazs Ree wrote at 2008-4-11 09:19 +0200:
...
In order to analyse a difficult problem, I added "from dm.pdb import zpdb; zpdb.set_trace()" in the doctest ("dm.pdb.zpdb" is my Zope aware PDB extension)
The standard PDB works fine. I'm sure you're extended version can be tweaked to as well.
I have similar issues with ipdb. - similar in sense that I cannot use it when running from doctests.
Any any other debugger, too, will have problems. Usually, I am no fan of "explicit is better than implicit". But, in this case, I think it would give a much better solution. Apparently, the debugger integration works by wrapping some class ("_OutputRedirectingPdb") around a given debugger and then use this debugger instead of the wrapped on. How about documenting this wrapping class. Then any debugger author can use the class to wrap his debugger and use it. For this special case, we do not need monkey patching. import myWrappedDebugger; myWrappedDebugger.set_trace() (or for the standard debugger: "from zope.testing import pdb; pdb.set_trace()") is only slightly more complex than import pdb; pdb.set_trace() -- Dieter
participants (4)
-
Balazs Ree -
Benji York -
Dieter Maurer -
Marius Gedminas