[Python-Dev] Using logging in the stdlib and its unit tests (original) (raw)

Robert Kern robert.kern at gmail.com
Wed Dec 8 03:33:33 CET 2010

On 2010-12-07 17:58 , Vinay Sajip wrote:

Robert Kern<robert.kern gmail.com> writes:

If I had my druthers, I would simply remove the "No handlers could be found for logger XXX" message. If we always wrote entire applications from the ground up, it makes a lot of sense. The person that writes the code that issues logs is the same person that writes the code to configure logging for reading. If you add logging in one place, you almost certainly want to use it somewhere else and not setting up logging is probably an error. But when you want to write reusable libraries, those roles become separated. Exactly - we do use third-party libraries. When logging was added there was some debate about whether this one-off message should be printed, and in balance it was thought better to print this, not least because people would be unfamiliar with logging (as it was then new) and so be not unlikely to misconfigure it. No indication of this at all would be double-plus-ungood.

I really don't understand how this view can be consistent with the practice of adding NullHandler to loggers. If this message is so important to prevent misconfiguration, then why should a library author decide to silence it for his users?

I think that the chances of a misconfiguration that the warning would catch. are small in practice. I don't have any solid survey data on how people configure their loggers, but I strongly suspect that almost all configurations include a catch-all root logger and that most of those only consist of that root logger.

As a library author, I would dearly love to just add logging liberally without placing any additional burden to the users of my library. If my users wants to read those logs, he will configure logging. If he doesn't, he won't. With the current behavior, I can't do that. If I add logging, he has to add code just to silence a message that is meaningless to him (after I get the support emails asking if things are broken and explain how to silence it). If I add a NullHandler, I remove the ability for him to use logging.basicConfig(), the easiest and most straightforward way for him to add logging to his application. You don't remove the ability for him to use basicConfig() - that's another mistake in your post (you already corrected the other mistake in your self-response). See my example with mylib.py/myapp.py in another post on this thread, in response to Antoine.

Same mistake. I intended the correction to apply to all such statements in my post.

This is only my personal anecdotal experience, but the current behavior has always wasted my time and never saved any of my time. That's because I think you're doing it wrong, or else I've misunderstood your use case.

I will try to state it more plainly: the message has always been a false positive in my experience. It has never helped me fix a real problem and has otherwise wasted my time.

NullHandler is the way to go, and doesn't preclude the use of basicConfig() UNLESS you choose to add the NullHandler to the root logger (not what you're supposed to do - you're supposed to add it to the top-level logger of your library, not the top-level logger of the logging hierarchy.)

See the mylib/myapp example and tell me which it is - your mistake or mine?

I think that boilerplate should be minimized. If using getLogger() should almost always be followed by adding a NullHandler, then it should be the default behavior. The easiest way to achieve this effect is to simply not issue the warning message.

-- Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

More information about the Python-Dev mailing list