Debugging Django: print statements?

[rzimerman]

What's the best way to do debugging in Django? Usually when I program,
I use "print" statements to identify problems. But Django seems to
surpress all output to stdout.

I read at djangobook.com that I could put "assert False" statements in
problematic parts, and then I would see debugging output through the
web interface. However, this doesn't let me 1) pick the fields to
display, 2) continue execution of the program after the "assert False"
statement.

How do you debug your Django apps?

Thank you,
Robert

[JP]

> What's the best way to do debugging in Django? Usually when I program,
> I use "print" statements to identify problems. But Django seems to
> surpress all output to stdout.

Hi Robert,

the best way to do debugging is - as always - using a debugger:
http://docs.python.org/lib/module-pdb.html

JP

[Bryan Murdock]

I have used print statements with the built-in webserver. The output
showed up in the terminal where I ran manage.py runserver.

Bryan

[Filipe Correia]

Check this thread:
http://groups.google.com/group/django-users/browse_frm/thread/a9ed968d854c634c/3216dec1234ce0ac

I haven't found better ways to debug since then. I find the simplest
way for me has been to use print statements along with the built-in
webserver. I'm still looking forward the next version of pyscripter
though, which will apparently be able to debug django apps as it will
include a new remote debugging feature:
http://groups.google.com/group/PyScripter/browse_frm/thread/c63606868214be66

HTH,
Filipe Correia

[Vadim Macagon]

Eclipse + PyDev is working out for me pretty well, PyDev has a graphical
debugger.

[Margaret]

yup, me too

--
mawe...@gmail.com
13585201588

[alex.v...@gmail.com]

Sometimes you can run a parts of complicated code standalone, then I
am using _winpdb.py

Debugging with print statements is one of the things which I love about
django. I do not understand
why looking at the debug console output is not enough ?
Probably you are trying to debug production sites under mod_python or
mod_fcgi? I think its wrong.
Correct way to debug in dev. mode, and when program works fine, put it
to production.

Alex

[Kenneth Gonsalves]

On 23-Jan-07, at 11:13 AM, alex.v...@gmail.com wrote:

> Correct way to debug in dev. mode, and when program works fine, put it
> to production.

yes, but then deadlines dont always allow for that

--

regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/

[Austin Govella]

On 1/23/07, Kenneth Gonsalves <law...@thenilgiris.com> wrote:
> yes, but then deadlines dont always allow for that

Then you need a debugger *and* new deadlines.

--
Austin Govella
Thinking & Making: IA, UX, and IxD
http://thinkingandmaking.com
austin....@gmail.com

[alex.v...@gmail.com]

Kenneth Gonsalves wrote:
> On 23-Jan-07, at 11:13 AM, alex.v...@gmail.com wrote:
>
>
> > Correct way to debug in dev. mode, and when program works fine, put it
> > to production.
>
> yes, but then deadlines dont always allow for that

Nothing stops you from running both production mode server and dev.
server same
time.

If we are talking about debugging Django application itself (not the
production environment
but the application code) then this approach works well, and more then
well.

With PHP for example,every debug statement I would use on production
server, will
be seen by end users. In django, I easily fire up dev. server, debug
and fix the problem
without getting users annoyed by my debug statements. I beleive all
user should
see in case of internal server error for example is the "Internal
server error" well
designed page. No debug statements. Nothing else. Thats security.

Alex

[Vadim Macagon]

This seems to have veered off in a strange direction, the original
poster made no mention of debugging in a production environment. He
simply asked for something more efficient than print statements.

-+ enlight +-

[Julian Romero]

On 1/22/07, rzimerman <rzim...@gmail.com> wrote:

What's the best way to do debugging in Django? Usually when I program,
I use  "print" statements to identify problems. But Django seems to
surpress all output to stdout.

The best way, no doubt, is a graphical debugger that remotely connects to a running django. I am still looking for such beast (for linux environment...perhaps pydev is able to do that)

In the meantime I usually use two aproaches:
1) a dev server with print statements in the console
2) I have the base template ready to dump debug data as javascript block, basically sentences calling firebug's extension console.log method. The debugging code only runs when a specific parameter (__debug__=1) is added to the URL. You need collect data in the problematic view and add it to the context, then cycle over it on the template generating the javascript code. For IE lovers (or firebug haters) the same approach works dumping the data in a hidden HTML element. Valid for any server deployment. It doesn't annoy the users unless they add the parameter to the URL..

You can also write to the server (mod_python, fcgi) error log if you have access to it.

regards,
j.

[sandro dentella]

I'd like to stress the first answer was much simpler: pdb module.
You just need to 'import pdb' in you code (dev environment) and place a
'pdb.set_trace()'. When the view arrives there you get an interactive
pdb shell in the console, you can view variables, step throught the
code and so on. What else do you need?

cheers
sandro
*;-)

[Filipe Correia]

Haven't used pdb yet. 'pdb.set_trace()' would be added on the source
code to be debugged, right?
Having to change the source code to debug it doesn't feel very right...

Filipe

On Jan 23, 3:42 pm, "sandro dentella" <sandro.dente...@gmail.com>
wrote:

[John DeRosa]

Filipe Correia wrote:
> Haven't used pdb yet. 'pdb.set_trace()' would be added on the source
> code to be debugged, right?
> Having to change the source code to debug it doesn't feel very right...

And adding print statements is...what?

[Filipe Correia]

> > Having to change the source code to debug it doesn't feel very right...
> And adding print statements is...what?

I agree :) And that's why, to me, neither seem the right way to go...
(then again, using prints is the most effective way I have found, and
I guess pdb is probably equivalent)

Filipe

[Don Arbow]

Actually, pdb is much more effective and not the same as print
statements. In the debugger, you can not only print out variable
values, but you can change those values as well. You can't do that
with print statements. With a print statement, you need to specify
which value you want to print before execution. In the debugger, you
can look step through your program a line at a time and look at any
value you can think of.

Using print statements to debug a program is like figuring out what
is wrong with your car by listening for weird noises. Using a
debugger is like opening the hood and tweaking the engine with tools.

Don

[Julian Romero]

On 1/27/07, Don Arbow <don...@nwlink.com> wrote:

Using print statements to debug a program is like figuring out what
is wrong with your car by listening for weird noises. Using a
debugger is like opening the hood and tweaking the engine with tools.

Opening the hood seems a good approach...but you need to stop the car. The same goes for pdb vs. print statements.
(I talk about production server)
regards,
--
Julián

[deaston]

Hi Filipe,

Tried to post a reply earlier but managed to screw it up. If that
never makes it, here it is again...

To configure PyScripter to debug Django interactively:

1) Install a version of PyScripter that supports remote debugging
(I'm using 1.8.0.0)
2) Select "Run->Python Engine->Remote"
3) Set "Run->Command Line Parameters" to "runserver --noreload"

Then when you are ready to debug, do the following
4) Open "manage.py" from you Django project (make sure its the active
document)
5) Select "Run->Debug" (don't forget to set a break point)
6) Hit your app from a browser

It should stop at your breakpoint (assuming you set one on code that
was actually executed). Now you should be able to step through the
code, view variables, set watches, etc.

Only drawback is that you can't "stop" it gracefully other than to
reinit the engine. (let me know if you figure that part out)

Dan

On Jan 22, 5:25 pm, "Filipe Correia" <fcorr...@gmail.com> wrote:
> Check this thread:http://groups.google.com/group/django-users/browse_frm/thread/a9ed968...

>
> I haven't found better ways to debug since then. I find the simplest
> way for me has been to use print statements along with the built-in
> webserver. I'm still looking forward the next version ofpyscripter
> though, which will apparently be able to debug django apps as it will

> include a new remote debugging feature:http://groups.google.com/group/PyScripter/browse_frm/thread/c63606868...
>
> HTH,
> Filipe Correia

[Filipe Correia]

Hi Dan, thanks for posting this.
I know the latest versions of pyscripter now have remote debugging,
but haven't come around to use it yet. I'm glad to know it works with
django apps, I'll give it a go as soon as I can.

Cheers,
Filipe

[Frankie Robertson]

Well personally I wouldn't ever repair a moving car. Honestly, to me
at least, it seems your continuation of this analogy has proved why
what you're doing is a bad idea.

Why not keep the project in source control? Keep a global_settings.py
and import it into your settings.py. Next, keep separate settings.pys
for development and production and as soon as you've fixed a bug or
want to release a new version of the site just do a commit at the
development end and an update at the production end and restart
apache/your fastcgi thingy. If there are inconsistencies between the
environments then that's a configuration problem. If it's a big site
you could create a tag for each version and create and checkout a new
tag for each version of the site.

As for the original topic, I used to use print, but then you have to
keep going back and changing what you want. So I just use pdb as in a
lot of ways it acts like a superset of print.
--
http://grimboy.co.uk

[TaMeR]

Hello coders,

I found this debug tool for Django at djangosnippets.org and was
wondering if I could get some help for that.

Even know I have DEBUG = True and TEMPLATE_DEBUG = DEBUG set in the
Django Settting.py in my template
this: {% if debug %}
or this: {% if DEBUG %}
is not set at all.

I can import the setting via
return object_list(extra_context={'DEBUG': settings.DEBUG})

But that does not help since the code needs sql_queries as well,
anyway I thing I am doing something wrong here but I can't figure it
out.

I am using "return render_to_response" so RequestContext should be
set.

What else is there?

Here is the link to the code:
http://www.djangosnippets.org/snippets/93/

Thanks