Thanks for the replies.

The problem I described earlier exhibits only in Django doctest. If
you write a doctest and run with plain python interpreter, such as
this:
test.py
def print_i(i):
    """
    >>> i = 1 + 1
    >>> i
    2
    >>> import pdb; pdb.set_trace()
    """
    print i

$ python -m doctest test.py
you will get the interactive debugger to do "p i", "w", "locals()"
etc. So, I don't think it is a problem in pdb, or doctest in that
matter.

Unless I am missing the obvious, I believe Django replaces the stdout
with it's own version of output (django/test/_doctest.py,1152) that
simply won't print in debug mode. Having said that, is it not possible
to activate debugger in Django doctest?


On Dec 16, 8:08 am, Bill Freeman <[email protected]> wrote:
> Or maybe:
>
>   import pdb, sys; pdb.Pdb(stdin=sys.__stdin__,
> stdout=sys.__stdout__).set_trace(sys._getframe().f_back)
>
> On Tue, Dec 15, 2009 at 5:32 PM, Bill Freeman <[email protected]> wrote:
> > Untested, but it looks like you can do:
>
> >   import pdb, sys; pdb.Pdb(stdin=sys.__stdin__,
> > stdout=sys.__stdout__).set_trace()
>
> > On Tue, Dec 15, 2009 at 11:07 AM, Bill Freeman <[email protected]> wrote:
> >> 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 <[email protected]> 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 [email protected].
> >>> To unsubscribe from this group, send email to 
> >>> [email protected].
> >>> For more options, visit this group 
> >>> athttp://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 [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.


Reply via email to