Géry <gery.o...@gmail.com> 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 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 (https://github.com/python/cpython/blob/master/Lib/logging/config.py#L161). 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36318> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
