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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
