On 09/06/2016 04:57 PM, Ivan Sagalaev wrote: > I'm > talking about this function: > https://github.com/django/django/blob/master/django/utils/log.py#L66 > > When `LOGGING_CONFIG` isn't explicitly disabled it first unconditionally > initializes logging with the hard-coded configuration and then applies a > user one, if present. And the latter can't really neutralize the effect > of the former.
FWIW I agree that the current behavior here is broken and should be fixed. The design seems to be based in an assumption that `disable_existing_loggers=True` can "undo" the effects of the previous config, when it can't, and in fact it does something much nastier -- it silences all previously-created loggers. I clearly recall outlining this issue in a Trac ticket at some point quite a while ago, but I can't seem to find that ticket now. Fixing this in a way that doesn't change logging behavior for projects upgrading from a previous Django version may be tricky, unless we gate the effect of the change on (yet another) setting. Carl -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/21d52615-35ac-4091-92c9-4ef14fbd4e0f%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
