IIUC, the test jig redirects stdin and stdout so that it can drive interpreter input from the corresponding substrings of the doc test strings, and capture the output to compare it to the corresponding substrings of the doc test strings. So pdb is waiting for input from the doctest string and it's output is captured by the test framework instead of printed.
One approach would be to, rather than simply calling set_trace(), create a function of your own to call instead, which rebinds stdin and stdout (and maybe stderr) to the terminal, and then calls set_trace() itself. There are two variants on this approach: If you restore the test framework versions of I/O after set_trace(), then you can print stuff, but single stepping and setting breakpoints is not going to work. You can, however, use the continue command to run further in the test. If you don't restore the test framework I/O, then pdb will work, including breakpoints and single step, but all bets are off if you step or run to the point that you have returned to the test framework. Another approach is to hack pdb so that every time that it is entered it saves the existing I/O and sets things to the terming, and every time it transfers back to the program (s, n, r, c) it restores the I/O. You can even step into the test framework with something like this. A possible confusion could occur with non-complete line I/O, but maybe not. (I wouldn't be surprised if there weren't something like this already in pdb, but to complex to mention in the simple user documentation. Or not. A third possibility is a hacked pdb that can be told to interact over a tcp socket, or, on *nix, a pseudo tty. Then you wire up telnet or an xterm, and drive pdb from there, without fiddling with stdin, stdout, and stderr at all. (This would definitely be a cool addition to pdb, if it's not already there.) And, of course, you can always sprinkle in code to append informational lines to a file. This is the equivalent of the print statement approach, except that you must open a file for append and print (or write) to that, and close it. You might also manage this with the logging facility. Bill On Mon, Dec 14, 2009 at 5:21 AM, Phui Hock <phuih...@gmail.com> wrote: > Suppose I have the following in app 'app'. > from django.db import models > class Test(models.Model): > """ > >>> v = "Hello, world!" > >>> import pdb; pdb.set_trace() > """ > > Running manage.py test app will drop me to an interactive debugger > mode but no output. How to execute the usual p, j, s etc? > > -- > > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
