python logging filter limitation, looks intentional?
chris at simplistix.co.uk
Tue Jan 17 01:07:19 EST 2012
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...
Simplistix - Content Management, Batch Processing & Python Consulting
More information about the Python-list