Greg Werbin <outth...@me.gregwerbin.com> added the comment:
Hi, thanks for the comment. > First of all, library developers should not be configuring loggers at all, > other than adding a NullHandler to their top-level logger. This is true, and I agree. I am not expecting people to start using basicConfig() inside their libraries. > Secondly, it is fine to configure the root logger and then log to any other > logger. The default mechanisms mean that handlers added to the root logger > are used by loggers which are anywhere in the logger hierarchy. So users that > are using basicConfig() but other loggers than the root logger may be using > the system as designed. This change serves the purpose of making it easier to configure non-root loggers. Library developers often add logging to their libraries, expecting that end users will never see those log messages. However, if you configure the root logger in your application, you will see those log messages. This change is intended to let users more easily configure the specific loggers that they want to configure, without also getting a lot of extraneous output from loggers that they don't care about. I have seen experienced Python developers misunderstand how this works, and go through all kinds of ugly contortions (setting filters on handlers, etc.) to avoid the boilerplate of instantiating Handler and Formatter objects. > Thirdly, logging.config.dictConfig() allows usage of a dictionary to > configure multiple loggers, handlers etc. all at once, for use cases which > are more demanding than basicConfig(). It doesn't make sense to do what > you're proposing, since it appears to offer a different way of configuring > other loggers than the root logger, when dictConfig() already offers that. Good point. I am proposing an alternative interface to the functionality provided by dictConfig(). I would frame this proposal as a third configuration option, with complexity somewhere between the current basicConfig() and dictConfig(). Also, using the kwarg means better support for IDE tab-completion and type checking, and another opportunity for discoverability in the docs. On that note, it would be nice to adjust the type stubs for dictConfig() to use a TypedDict with types corresponding to the "dictionary configuration schema" (https://docs.python.org/3/library/logging.config.html#logging-config-dictschema) instead of Any (see https://github.com/python/typeshed/blob/ee48730/stdlib/logging/config.pyi#L22). But that's a separate change. I'm happy to make a PR to Typeshed for it, though! Regardless of whether this change is accepted, I also think there should be a note about dictConfig() in the docs for basicConfig(): https://docs.python.org/3/library/logging.html#logging.basicConfig. I believe a lot of users simply don't know about the "low-boilerplate" options for logging configuration in Python, so they either don't do it right or don't do it at all and use print(). Both are bad outcomes. Again, I'm happy to make a separate PR for that change. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue45027> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
