RE: [Python-Dev] Consistent logging in the standard library

Quoth Matthew F. Barnes:
An application may want to organize things differently. For example, it may want to redirect asyncore's log messages to a logger named "myapp.network.asyncore"
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?

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. The use case for a .setlogger() method on the various objects that perform logging is different, so that is still needed. Generally, I'm not convinced that a getdefaultlogger() is needed or helpful (it seems an implementation default for the module), though I'm not at all opposed to the setdefaultlogger() for the affected modules. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

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
participants (3)
-
Fred L. Drake, Jr.
-
Matthew F. Barnes
-
Michael Chermside