mirror of https://github.com/zulip/zulip.git
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.
This commit is contained in:
parent
8e2ae66fe6
commit
500d81bf2c
|
@ -1048,7 +1048,7 @@ DEFAULT_ZULIP_HANDLERS = (
|
||||||
|
|
||||||
LOGGING = {
|
LOGGING = {
|
||||||
'version': 1,
|
'version': 1,
|
||||||
'disable_existing_loggers': True,
|
'disable_existing_loggers': False,
|
||||||
'formatters': {
|
'formatters': {
|
||||||
'default': {
|
'default': {
|
||||||
'format': '%(asctime)s %(levelname)-8s %(message)s'
|
'format': '%(asctime)s %(levelname)-8s %(message)s'
|
||||||
|
|
Loading…
Reference in New Issue