python logging filter limitation, looks intentional?

[Chris Withers]

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