Thanks Tim, let me make sure I understand the current functionality:
- django.request is the logger for views (broadly speaking) any logging "elsewhere" would go to logger "django" instead.
- django.request is set to propagate=False
- if DEBUG is False, an exception in a view would go to mail_admins, but *not* to the console, because propagate=False
- if DEBUG is False a
logging.info outside of django.request would end up going nowhere anyway, because the console handler has require_debug_true
- if DEBUG is True, an exception in a view goes only into the rendered debug HTML message
- if DEBUG is True, a
logging.info in a view goes nowhere, because
propagate=False (a quick test confirms this, but i may have done it
wrong?)
- if DEBUG is True, a
logging.info outside of django.request would go to the console
So I have two questions:
1/ what is the scope of django.request? Am I right in thinking it's "pretty much everything you normally do with django" because it's "any code that's invoked while handling a wsgi request" - so, in normal use, everything in views.py, forms.py, models.py etc.... the only obvious way i can think of not going through a request would be a management command?
2/ wouldn't it be better if, when DEBUG=True, more logging stuff ended up in the console? logging for management commands going to stderr by default is great, but wouldn't it be cool if
logging.info and logging.exception in a view also went to stderr?
Happy to update the docs if i can get answers up to 1/ at least :)