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.

classification
Title: logging documentation for library cleanup
Type: behavior Stage: resolved
Components: Documentation Versions: Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: docs@python Nosy List: ajs, chris.jerdonek, docs@python, r.david.murray, vinay.sajip
Priority: normal Keywords:

Created on 2013-01-29 18:05 by ajs, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (3)
msg180919 - (view) Author: Aaron Sherman (ajs) Date: 2013-01-29 18:05
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...
msg180927 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2013-01-29 18:45
> This documentation states that libraries can turn off logging by adding a NullHandler:

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:

> It only holds true if the application which calls the library has not called basicConfig on the root logger.

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?

> The correct way for a library to silence log messages is to both set a NullHandler and set propagate to false.

This doesn't sound like good practice to me and isn't what the current docs were trying to say.
msg180940 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-01-29 19:33
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.
History
Date User Action Args
2022-04-11 14:57:41adminsetgithub: 61277
2013-01-29 19:33:57r.david.murraysetstatus: pending -> closed

nosy: + r.david.murray
messages: + msg180940

resolution: not a bug
stage: resolved
2013-01-29 18:45:01chris.jerdoneksetstatus: open -> pending
nosy: + chris.jerdonek, vinay.sajip
messages: + msg180927

2013-01-29 18:05:06ajscreate