Opened 3 years ago

Closed 11 months ago

#20229 closed Uncategorized (needsinfo)

Django 1.5 calls the LOGGING_CONF function twice

Reported by: lsaffre Owned by: nobody
Component: Core (Other) Version: 1.5
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


It took me some time to find out that even setting
disable_existing_loggers to True doesn't help: Django 1.5
will call my LOGGING_CONFIG function *twice*: once
with hard-coded default values, then another time with the local settings.
IMHO this is not nice behaviour.

Change History (8)

comment:1 Changed 3 years ago by claudep

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Could you please explain what is your problem exactly? The second call with your local settings should take precedence if you set disable_existing_loggers to True.

comment:2 Changed 3 years ago by lsaffre

I don't have a problem, I discovered a detail where Django can get better and am trying to share it.

The docs say that "the project’s logging configuration is merged with Django’s defaults", but if you
look at the code, then Django doesn't merge anything, it calls a function twice.
I cannot imagine any meaningful usage for what Django is doing there since version 1.5:


if self.LOGGING:


I'd rather suggest something like:


config = dict()
if self.LOGGING:



comment:3 Changed 3 years ago by claudep

  • Component changed from Uncategorized to Core (Other)

I think it would be clearer if we could take a real use case here, where the current code would make it fail, and the new succeed. Can you provide such a use case, please?

comment:4 Changed 2 years ago by lsaffre

No I have no real use case, it is just so obviously dangerous... But OK you're right, let's close this ticket because there are more important things to do than to worry about theoretic dangers!

comment:5 Changed 2 years ago by claudep

  • Resolution set to worksforme
  • Status changed from new to closed

I'm sorry, but I still do not see what the real issue is. But it's totally possible that I misunderstood logging config in general.
So don't hesitate to reopen if you can show practically how it is "obviously dangerous".

comment:6 Changed 11 months ago by poirier

  • Resolution worksforme deleted
  • Status changed from closed to new

I think I can clarify why this is a problem.

Using Django settings, there's no simple way to completely override the default Django logging configuration, because in Python, once a logging config has been applied, applying another one only updates the current configuration, it does not replace it. So if you want to completely control the logging configuration using the Django settings, you have to track down what the default Django logging configuration is and be careful to specify your own versions of every logger in the default configuration that doesn't happen to be exactly what you want. (And that's not even going into what happens if you set disable_existing_loggers to True.)

It would be much, much simpler if Django just applied the logging configuration in settings.LOGGING, if any, and only used its own default if LOGGING was not set otherwise. That would make it possible to set exactly the logging configuration you want using Django settings, and would also work the same way as most other Django settings.

comment:7 Changed 11 months ago by timgraham

Could you raise the issue on the DevelopersMailingList? That would obviously be backwards-incompatible unless we had a switch to control the behavior.

comment:8 Changed 11 months ago by timgraham

  • Resolution set to needsinfo
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.
Back to Top