On 17/01/2012 10:48, Vinay Sajip wrote:
From: Chris Withers<ch...@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.
How about an option that defaults to "backwards compatibility mode" for
Python 2.7, flipped the other way in 3.3?
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.
See above ;-)
I don't want people to have to code differently for Python 3.3 and for older
versions.
I must stress again, we're talking about a configuration change, not a
code change, given the massive changes people are going to have to make
between 2 and 3 anyway, I don't think that's unreasonable...
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),
Yeah, just feels a bit icky...
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.
A module-level flag would be ideal :-)
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
--
http://mail.python.org/mailman/listinfo/python-list