New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
logging documentation for library cleanup #61277
Comments
This documentation states that libraries can turn off logging by adding a NullHandler: http://docs.python.org/2/howto/logging.html#configuring-logging-for-a-library This is not entirely true. It only holds true if the application which calls the library has not called basicConfig on the root logger. If it has, you get logs to both the root logger and the NullLogger, defeating the point of having added a NullLogger in the first place. The correct way for a library to silence log messages is to both set a NullHandler and set propagate to false. For an example of the behavior on the current docs, see: import logging
import sys
# Application configures its root logger
logging.basicConfig(level=logging.DEBUG)
# Library configures a NullLogger:
logger = logging.getLogger('foo')
logger.setLevel(logging.DEBUG)
handler = logging.NullHandler()
handler.setLevel(logging.DEBUG)
logger.addHandler(handler)
# Library then logs:
logger.warning("BLAH") This example is not terribly interesting, but the more interesting example is when the library configures a real log handler (e.g. in order to create a separate security log in an authorization module). In this case, the log messages will be sent to both the file log and the root logger by default, as long as any part of the application has configured the root logger. IMHO, propagate should always be False for all new loggers, but at the very least the fact that it is True should be documented in the section on library logging... |
I don't think that's what the documentation says. It says, "If for some reason you don’t want these messages printed *in the absence of any logging configuration* [my emphasis].... If the library user configures logging for application use, presumably that configuration will add some handlers, and if levels are suitably configured then logging calls made in library code will send output to those handlers, as normal." In other words, the documentation is acknowledging that logging won't get turned off if something else configures it. This is the same as what you say further on:
If there's some other part of the documentation that says otherwise, can you include a direct quote in the comment so we know what words you are referencing?
This doesn't sound like good practice to me and isn't what the current docs were trying to say. |
Indeed. The whole point of that section is to explain how the library can refrain from spewing unwanted logging *if the application doesn't care about logging*. If the application does care (has configured logging), it would be wrong to block the logging. I believe there is now a NullHandler or something similar set up by default, so I don't think this issue arises in Python3. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: