This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author maggyero
Recipients maggyero, vinay.sajip
Date 2019-03-18.16:49:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> It would be better to set the level of those loggers to e.g. ERROR or CRITICAL rather than disabling them altogether - presumably if something bad happens in those packages, one would want to know!

What if the user doesn't care anyway? Why assuming what the user wants? And with solutions 2 and 3, the user can already *completely* silence a specific logger from `logging.config.dictConfig`. So it cannot be the reason why the `disabled` attribute cannot be set from `logging.config.dictConfig`.

> I don't especially want people to use `disabled` for this type of thing - the main reason for having it is that following an on-the-fly reconfiguration in a long-running process, some threads might still be active that contain references to now-unwanted loggers, and disabling makes those references inactive without the need to track them down.

I think you are referring to the `disable_existing_loggers` key in `logging.config.dictConfig`, which sets the `disabled` attribute for loggers present in a previous configuration but absent in the new configuration (

So a user can already deactivate *all* existing loggers from `logging.config.dictConfig`. What if he wants to deactivate only *one* specific logger, but not all (for whatever reason)?

If the `disabled` attribute should not be part of the public API, it should have been name `_disabled`. Currently everyone can type this anyway:

import logging

logging.getLogger("foo").disabled = True

So it should be doable from `logging.config.dictConfig` too in my opinion.
Date User Action Args
2019-03-18 16:49:09maggyerosetrecipients: + maggyero, vinay.sajip
2019-03-18 16:49:09maggyerosetmessageid: <>
2019-03-18 16:49:09maggyerolinkissue36318 messages
2019-03-18 16:49:09maggyerocreate