[Python-Dev] Using logging in the stdlib and its unit tests

[Robert Kern]

On 2010-12-07 17:58 , Vinay Sajip wrote:
> Robert Kern<robert.kern<at>  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