From 500d81bf2cc25f05b29e49254dc7ed7076deacc2 Mon Sep 17 00:00:00 2001 From: Greg Price Date: Mon, 25 Sep 2017 14:46:44 -0700 Subject: [PATCH] logging: Stop forcing pre-Python 2.5 legacy config behavior. The `disable_existing_loggers` option to the `logging.config` module turns on a rather complicated behavior of disabling some, but not all, loggers that might have been already configured when the call to `logging.config.dictConfig` or `logging.config.fileConfig` is made: > This behaviour is to disable any existing loggers unless they or > their ancestors are explicitly named in the logging configuration. (https://docs.python.org/3/library/logging.config) Turns out the only reason this is there is as a compatibility hack to match the behavior of Python 2.4 and below. See the thread where the new behavior was introduced: https://bugs.python.org/issue3136 Just as the author of the new behavior explains in that thread from 2008, the legacy behavior forces all logging configuration to be awkwardly centralized in one place. That makes the code harder to read, and it perennially causes confusion when a perfectly normal-looking `logging.getLogger` call at the top level of one module mysteriously has no effect, while that in another module works fine, under the influence of the details of what gets imported when. So, switch to the shiny new behavior of Python 2.5. Here LOGGING is a Django setting which just becomes an argument to logging.config.dictConfig. This may cause a few of the logfiles in ZULIP_PATHS to become active that have been dormant for a long time. --- zproject/settings.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zproject/settings.py b/zproject/settings.py index 46f5607a5c..b701e0f2ab 100644 --- a/zproject/settings.py +++ b/zproject/settings.py @@ -1048,7 +1048,7 @@ DEFAULT_ZULIP_HANDLERS = ( LOGGING = { 'version': 1, - 'disable_existing_loggers': True, + 'disable_existing_loggers': False, 'formatters': { 'default': { 'format': '%(asctime)s %(levelname)-8s %(message)s'