Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #19056

Re: python logging filter limitation, looks intentional?

Show key headers only | View raw

> From: Chris Withers <chris@simplistix.co.uk>

> 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...

Well, it means that filters that don't get called now would get called - and that's a change in behaviour.

It's not a bug, because it's like that by design. I understand that you don't agree with that particular design decision, but it's out there now. What you're asking for isn't unreasonable, but not achievable without a change in behaviour. I don't want people to have to code differently for Python 3.3 and for older versions.
 
> 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.

Okay,  then applying a filter on handlers is a way of achieving this.

> Again, this doesn't help if the __name__-ish loggers are in third party 
> packages that you don't want to have to fork ;-)

True, but as I said earlier, you can attach a filter to your handlers. It's rather unlikely that you would have more than half-a-dozen handlers (since handlers ~= potential audiences for log events), but even so, I can't believe it's especially onerous to set up filter configuration for those handlers - and even easier if you add a DelegatingHandler to the mix. In https://gist.github.com/1623702 I've shown a DelegatingHandler; it's quite short.
 
> Both use cases are valid, and a DelegatingHandler just feels like a hack to work 
> around a deficiency in the framework...

Rather, the approach I've taken is not to assume I'll meet everyone's needs out of the box, but that the right pieces are in place for people to use logging in useful ways in scenarios that I haven't thought of - which shortcomings might well be termed "deficiencies" according to your point of view - by deriving and overriding classes, or by composing using filters, or setting module-level flags. There are numerous examples on e.g. Stack Overflow where a small amount of customisation (e.g. a custom handler like DelegatingHandler) has been suggested to meet a specific user requirement. I don't think of these as hacks - I occasionally have to subclass stdlib classes in other areas to get the behaviour I want, and that's part and parcel of having OO at your disposal.

Regards,

Vinay Sajip

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: python logging filter limitation, looks intentional? Vinay Sajip <vinay_sajip@yahoo.co.uk> - 2012-01-17 10:48 +0000

csiph-web