so, just to rephrase this, to help think about how the docs could be improved. If I understand things correctly:
*with the default settings, the only circumstances in which a logging message would end up in the console is outside of normal django request handling, for example in a management command, and only if DEBUG* is set to True. Is that correct? On 3 January 2014 15:44, Harry Percival <[email protected]> wrote: > 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 :) > > > On 1 January 2014 20:46, Tim Graham <[email protected]> wrote: > >> I believe tracebacks are handled by the 'django.request' logger, not the >> 'django' logger. >> >> You may find the commit that added that documentation and the related >> ticket helpful: >> https://github.com/django/django/commit/f0f327bb >> https://code.djangoproject.com/ticket/18993 >> >> Documentation improvements would be welcome if you feel they are >> appropriate. >> >> >> On Saturday, December 28, 2013 8:11:00 AM UTC-5, Harry Percival wrote: >> >>> The docs say: >>> >>> >>> *"All messages reaching the django catch-all logger when DEBUG >>> <https://docs.djangoproject.com/en/1.6/ref/settings/#std:setting-DEBUG> is >>> True are sent to the console. They are simply discarded (sent to >>> NullHandler) when DEBUG >>> <https://docs.djangoproject.com/en/1.6/ref/settings/#std:setting-DEBUG> is >>> False."* >>> https://docs.djangoproject.com/en/1.6/topics/logging/# >>> django-s-default-logging-configuration >>> >>> From reading that, I would (naively?) expect to see tracebacks in the >>> terminal I'm running manage.py runserver, if any of my views raise an >>> exception for example. I don't see any, however. >>> >>> Is this because the exception *is* caught, in that it gets intercepted >>> and turned into the nice django debug page? Am i misinterpreting the >>> docs? If so, would it be worth adding a couple of words of clarification >>> in case anyone else might misread it like me? Assuming anyone is that >>> silly? >>> >>> Of course, I would rather prefer it if exception tracebacks *did* go to >>> the console by default, as well as to mail_admins and/or to a nice django >>> debug page. But maybe that's just me. >>> >>> hp >>> >>> PS minimal repro: >>> >>> django-admin.py startproject myproj >>> python manage.py startapp myapp >>> >>> >>> >>> *urls.py:* >>> from django.conf.urls import patterns, include, url >>> urlpatterns = patterns('', >>> # Examples: >>> url(r'^$', 'myapp.views.home', name='home'), >>> ) >>> >>> >>> *myapp/views.py:* >>> def home(request): >>> raise Exception('arg') >>> >>> PPS apologies for x-post from django-users >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Django users" group. >>> To unsubscribe from this topic, visit https://groups.google.com/d/ >>> topic/django-users/tCw4bqw2tsI/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> To post to this group, send email to [email protected]. >>> >>> Visit this group at http://groups.google.com/group/django-users. >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/django-users/60d3c4c6-22f8-4de6-a376-6230c33ad0a9% >>> 40googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >>> -- >>> ------------------------------ >>> Harry J.W. Percival >>> ------------------------------ >>> Twitter: @hjwp >>> Mobile: +44 (0) 78877 02511 >>> Skype: harry.percival >>> >> > > > -- > ------------------------------ > Harry J.W. Percival > ------------------------------ > Twitter: @hjwp > Mobile: +44 (0) 78877 02511 > Skype: harry.percival > -- ------------------------------ Harry J.W. Percival ------------------------------ Twitter: @hjwp Mobile: +44 (0) 78877 02511 Skype: harry.percival -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACFvh98KH%2BimQR-1EoMj24S5i5ir5GCq4hYc1NQnejsdTiOXbQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
