On 16/01/2012 23:21, Vinay Sajip wrote:
Why is this? There must be some rationale for this rather than what, for me and
others I've talked to, would seem more natural, ie: a filter on the root
logger would get messages both logged to it and any messages propagated to it
from child loggers to process.
Perhaps you're right, but this can't be changed without breaking existing code,
AFAICT.
How breaking code? Configuration, maybe, but I can't see anyone being
upset that filtering would begin working "the same as everything else".
This just feels like a bug...
However, if you find your usage pattern occurring very commonly in your
applications, it's easy enough to create a DelegatingHandler handler class
which passes its events on to any number of handlers you like.
But this is just extra work when the normal built-in
delegation-upwards-ending-in-root works exactly as I want.
It's not in general useful to filter on message content, when one factors in
use of third-party libraries.
Actually, the filter I want to work on (log_nerf) is precisely for 3rd
party libraries; if a library author thinks a message should be error
but you think it should be debug, and vice versa, having a filter that
alters the level is the only way to sort things out without hacking the
3rd party library. I've also seen this technique used successfully where
the filter looks to a database for config and nerfs messages during a
certain time period.
Of course, if you are in control in the whole software stack you're using, or
in certain very specific scenarios, it may be more useful - but in general it's
most useful to filter on level and using logger names. The __name__ for loggers
is useful to locate the source of events to a module, but you can have child
loggers under that to log specific types of events in that module, and use the
verbosity of those sub-module loggers to control output.
Again, this doesn't help if the __name__-ish loggers are in third party
packages that you don't want to have to fork ;-)
It's also the opposite of what I'd need, I'd need to plug one
handler into all the specific loggers that get used (and bear in mind that many
libraries log to __name__ from modules and sub-modules) this is a pretty onerous
task :-(
I thought from an earlier comment - "rather than just the root logger where my
handlers live" - that you had your handlers attached to the root logger, in which
case it wouldn't be onerous at all. In place of those individual handlers attached to the
root, you simply attach your DelegatingHandler to the root logger, and attach the filter
and the other handlers to that DelegatingHandler instance.
Both use cases are valid, and a DelegatingHandler just feels like a hack
to work around a deficiency in the framework...
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
--
http://mail.python.org/mailman/listinfo/python-list
