What does disable_existing_loggers do?

disable_existing_loggers – If specified as False, loggers which exist when this call is made are left enabled. The default is True because this enables old behaviour in a backward-compatible way. This behaviour is to disable any existing non-root loggers unless they or their ancestors are explicitly named in the logging configuration.

1. Overview 

disable_existing_loggers is a configuration option used in Python’s logging.config.dictConfig() or fileConfig() to control whether previously defined loggers should be disabled when applying a new logging configuration. 

1.1 What It Does

• Default value: True

• Effect: Disables all existing non-root loggers unless they are explicitly named in the new configuration.

Example

logging.config.dictConfig({
    'version': 1,
    'disable_existing_loggers': True,
    'loggers': {
        'myapp': {
            'level': 'DEBUG',
            'handlers': ['console'],
        }
    },
    ...
})

If disable_existing_loggers is set to True, any loggers created before this configuration (e.g., from imported modules) will be disabled unless they are listed in the loggers section.

1.2 When to Use

Scenario	Recommended Setting
You want a clean slate	True
You want to preserve existing loggers (e.g. from libraries)	False

1.3 Important Notes

• This does not delete loggers — it disables them by setting .disabled = True.

• It affects non-root loggers only.

• If you set it to True, make sure to explicitly reconfigure any loggers you still want active.

2. Detailed Breakdown

2.1 “Disable any existing non-root loggers”

• When disable_existing_loggers: True is set in your logging config, Python will disable all loggers that:

  • Are not the root logger

  • Were created before the config was applied

  • Are not explicitly named in the config

These loggers(that meet the above three conditons all at once) will have their .disabled attribute set to True, which means they stop emitting log messages.

2.2 “Unless they or their ancestors are explicitly named”

This part is key.

• A logger is explicitly named if it appears in the loggers section of your config.

• A logger’s ancestor is any logger higher up in the hierarchy.

Logger Hierarchy Example

logging.getLogger("app")           # ancestor: root
logging.getLogger("app.views")     # ancestor: app
logging.getLogger("app.views.detail")  # ancestor: app.views

If your config includes "app" in the loggers section, then:

• "app" is kept active

• "app.views" and "app.views.detail" are also kept active (because their ancestor "app" is named)

But if "app" is not in the config, and disable_existing_loggers: True, then:

• "app.views" and "app.views.detail" will be disabled

• Unless they are explicitly listed themselves

2.3 Summary Table

Logger Name	In Config	Ancestor in Config	Disabled?
"root"	N/A	N/A	❌ No
"app"	✅ Yes	—	❌ No
"app.views"	❌ No	✅ "app"	❌ No
"thirdparty"	❌ No	❌ No	✅ Yes

2.4 Real-World Use Case

Let’s say you’re using Django, and you want to silence noisy loggers from third-party libraries like urllib3, but keep your own app’s loggers:

```yaml
disable_existing_loggers: True

loggers:
  django:
    level: INFO
    handlers: [console]
  myapp:
    level: DEBUG
    handlers: [console]
```

This will:

• Keep django and myapp loggers active

• Disable urllib3, requests, etc., unless you explicitly list them