Fred L. Drake, Jr. said: > > Michael Chermside writes: > > Seems like an uncommon request, but one which shouldn't be made > > impossible for those who want it. But couldn't it be achieved by > > writing a handler which simply re-logged the message at the new > > spot in the hierarchy? > > That would solve that use case handily; if that's the right approach, > such a handler should be provided as part of the standard set of > handlers. I agree, this seems much cleaner than what I've proposed. In fact, the "ForwardingHandler" idea could be submitted to SourceForge as a separate patch for logging, and then the issue drops out of this "consistent logging" PEP altogether. So that changes my proposal as follows: - The getdefaultlogger() and setdefaultlogger() functions go away. - The self.logger attribute of class instances can be initialized to logging.getLogger(__name__). - Some kind of "ForwardingHandler" can be added to the module's logger to forward messages elsewhere in the logging hierarchy. But this is not likely to be a common use case. Matthew Barnes
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