11👍
The output should be in the terminal, where django was started. (if you don’t started it directly, I don’t believe there’s a way to read it)
As linkedlinked pointed out, it’s the best to not use print
, because this can cause Exceptions! But that’s not the only reason: There are modules (like logging) made for such purposes and they have a lot more options.
This site (even when it’s from 2008) confirm my statements:
If you want to know what’s going on inside a view, the quickest way is to drop in a print statement. The development server outputs any print statements directly to the terminal; it’s the server-side alternative to a JavaScript alert().
If you want to be a bit more sophisticated with your logging, it’s worth turning to Python’s logging module (part of the standard library). You can configure it in your settings.py: here he describes, what to do (look on the site)
For debugging-purposes you could also enable the debug-mode or use the django-debug-toolbar.
Hope it helps! 🙂
7👍
Never use print, as once you deploy, it will print to stdout and WGSI will break.
Use the logging. For development purposes, is really easy to setup. On your project __init__.py:
import logging
from django.conf import settings
fmt = getattr(settings, 'LOG_FORMAT', None)
lvl = getattr(settings, 'LOG_LEVEL', logging.DEBUG)
logging.basicConfig(format=fmt, level=lvl)
logging.debug("Logging started on %s for %s" % (logging.root.name, logging.getLevelName(lvl)))
Now everything you log goes to stderr, in this case, your terminal.
logging.debug("Oh hai!")
Plus you can control the verbosity on your settings.py with a LOG_LEVEL setting.
2👍
The print shows up fine with “./manage.py runserver” or other variations – like Joschua mentions, it shows up in the terminal where you started it. If you’re running FCGI from cron or such, that just gets dumped into nothingness and you lose it entirely.
For places where I want “print” like warnings or notices to come out, I use an instance of python’s logger that pushes to syslog to capture the output and put it someplace. I instantiate an instance of logging in one of the modules as it gets loaded – models.py was the place I picked, just for its convenience and I knew it would always get evaluated before requests came rolling in.
import logging, logging.handlers
logger = logging.getLogger("djangosyslog")
hdlr = logging.handlers.SysLogHandler(facility=logging.handlers.SysLogHandler.LOG_DAEMON)
formatter = logging.Formatter('%(filename)s: %(levelname)s: %(message)s')
hdlr.setFormatter(formatter)
logger.addHandler(hdlr)
Then when you want to invoke a message to the logger in your views or whatever:
logger = logging.getLogger("djangosyslog")
logging.warning("Protocol problem: %s", "connection reset", extra=d)
There’s .error(), .critical(), and more – check out http://docs.python.org/library/logging.html for the nitty gritty details.
Rob Hudson’s debug toolbar is great if you’re looking for that debug information – I use it frequently in development myself. It gives you data about the current request and response, including the SQL used to generate any given page. You can inject into that data like a print by shoving the
strings you’re interested into the context/response – but I found that to be a bit difficult to deal with.
0👍
A warning: if you try to deploy code with print statements under WSGI, expect things to break. Use the logging module instead.
- Maintain SQL operator precedence when constructing Q objects in Django
- Generating single access token with Django OAuth2 Toolkit
- Django REST framework: Can a nested object access its parent object's details in a List View?
- Pycharm + Django 1.3 + STATIC_URL in templates = Unresolved static reference
0👍
If you are using apache2 server to run django application and enabled access & error logs, your print statements will be printed in the error logs.
While you running your application kindly do the following as root
user in linux,
tail -f /path-to-error-file.log
mostly apache2 logs will be in this location /var/log/apache2/
.
It will print when ever it finds print command in your function.
- Using Pre_delete Signal in django
- Django render_to_string() ignores {% csrf_token %}
- Converting a django ValuesQuerySet to a json object
- Django: migration x in app x has no Migration class
- How does Waitress handle concurrent tasks?