[issue36318] Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig

Piotr Dobrogost added the comment: I strongly agree with arguments given by the original poster. Stackoverflow's questions cited show the functionality of disabling logger is something people are looking for. Disabling logger by setting high enough level seems to be a workaround at best

[issue36318] Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig

Change by Piotr Dobrogost : -- nosy: +piotr.dobrogost ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36318] Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig

Change by Géry : -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue36318] Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig

Géry added the comment: > A bit late for that now Okay, so disabled is a private attribute so it should never be used anyway. And as it not documented anywhere in the official Python documentation, I think the current situation is fine. Thank you for the explanation, I am closing this issue

[issue36318] Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig

Vinay Sajip added the comment: > If the `disabled` attribute should not be part of the public API it should > have been name `_disabled`. A bit late for that now, and AFAIK it hasn't caused people insuperable problems heretofore - the code has been like this pretty much since the logging

[issue36318] Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig

Géry added the comment: > 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

[issue36318] Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig

Vinay Sajip added the comment: > Actually people do this all the time, to deactivate the logging of some > third-party libraries (me included). 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

[issue36318] Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig

Géry added the comment: Actually people do this all the time, to deactivate the logging of some third-party libraries (me included). For instance: * https://stackoverflow.com/questions/24344045/how-can-i-completely-remove-any-logging-from-requests-module-in-python *

[issue36318] Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig

Vinay Sajip added the comment: I don't see any value in configuring a logger which starts as disabled - making it completely useless - why would one want to do this? I don't think the "consistency" argument flies in this case. -- ___ Python

[issue36318] Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig

New submission from Géry : In the logging Python library, one can completely disable logging (for all levels) for a particular logger either by setting its `disabled` attribute to `True`, or by adding to it a `lambda record: False` filter, or by adding to it a `logging.NullHandler()` handler

[issue36318] Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig

Change by Géry : -- keywords: +patch pull_requests: +12334 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list