Sometimes the best way to debug something is to print some stuff to the page, and exit(), how can I do this in a Python/Django site?
e.g. in PHP:
echo $var;
exit();
Thanks
views:
213answers:
4
+5
A:
Put this in your view function:
from django.http import HttpResponse
return HttpResponse(str(var))
interjay
2010-04-30 20:45:37
I'm trying to do this from a Middleware class `process_request`, so returning a HttpResponse at that point wouldn't work, right?
Infinity
2010-04-30 20:52:06
Actually it does, after reading the Django docs it looks like if you return a HttpRequest, it stops everything else and just returns that. Thx!
Infinity
2010-04-30 20:56:37
Using HttpResponse would actually terminate the reminder of the view processing, where as either using print or adding to the template context can help you view the data passed.moreover if you have a debug toolbar installed, you can view all the passed context variables neatly presented in it.
phoenix24
2010-04-30 21:49:28
+5
A:
I just wanted to give an alternative answer: Simply use print statements and serve your django site with python manage.py runserver
In this case the print statements show up in your shell, and your site continues functioning as it would normally.
Keare
2010-04-30 21:11:17
Unless you are locked into debugging via Apache (or whatever), it's hard to beat the immediacy of running the development server and simply doing print()s. I often can do an observe-edit-reload-observe cycle in under 20 or 30 seconds.
Peter Rowell
2010-05-01 02:21:22
Just remember to remove those print statements when you're done - leaving them in will crash mod_wsgi!
shacker
2010-05-01 07:32:12
Use mod_wsgi 3.X and you can quite happily leave the 'print' statements in, even though your WSGI application is then not a portable WSGI application. Read 'http://blog.dscpl.com.au/2009/04/wsgi-and-printing-to-standard-output.html'.
Graham Dumpleton
2010-05-01 11:09:36
Apache/mod_wsgi can also be quite happily use to develop Django applications, including automatic code reloading. Read 'http://blog.dscpl.com.au/2008/12/using-modwsgi-when-developing-django.html' and 'http://blog.dscpl.com.au/2009/02/source-code-reloading-with-modwsgi-on.html'.
Graham Dumpleton
2010-05-01 11:11:35
A:
If you don't want to crash mod_wsgi on print's do this in your wsgi file
sys.stdout = sys.stderr
prints will then be sent to the error_log
Mike
2010-05-01 10:30:38
It isn't really correct to say that mod_wsgi will 'crash'. It is the use of 'print' to stdout which was wrong. The mod_wsgi module was purposefully trying to make you write portable WSGI applications by flagging what you were doing as wrong. No one seems to care though that their WSGI applications aren't portable and mod_wsgi gave up trying to make you do the right thing in mod_wsgi 3.0. In other words, this isn't needed in mod_wsgi 3.X and later. Read 'http://blog.dscpl.com.au/2009/04/wsgi-and-printing-to-standard-output.html'.
Graham Dumpleton
2010-05-01 11:07:52
A:
If you are using mod_wsgi you can say:
print var
raise SystemExit
The SystemExit exception will not actually cause the whole process to exit as it would normally, but only cause that request to exit, presuming that no higher code catches it and ignores.
Ensure you are using mod_wsgi 3.X. If using older mod_wsgi, you would need to instead say:
import sys
print >> sys.stderr
raise SystemExit
Other WSGI servers may also treat SystemExit in a request the same way, say you would need to experiment as to what happens if using other hosting solution.
For other information about debugging WSGI applications read:
Graham Dumpleton
2010-05-01 11:16:24