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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4