> [trying to strip the discussion down] > Vinay Sajip wrote: > > > this is an interesting point. LogRecord is the basic unit of the current > > logging. > > > But you can not pass customized (subclassed) LogRecords without them > > > beeing wrapped (read: contained) in another LogRecord instance. Thus > > > you have to e.g. access 'record.msg' in filters. Why two instances > > > where one is enough, more flexible and pretty straightforward? > > > > There aren't two instances. > > and > > > ... > > Next question: how to pass in this information? two choices spring to mind: > > > > 1. Use a keyword argument, extra_info=None. (...) A passed in > > value would become the extra_info attribute of the LogRecord. > > > > 2. Use the "msg" parameter, which all logging calls already have (...) > > it can be used by user-derived classes, which will find it in the msg attribute > > of the LogRecord. > > are not very consistent statements <wink>. No, because the first is saying how it *is*, the second is saying how it *could be*. You see how hard I'm trying to accommodate you? <wink> > > Slightly OT: There's a lot of people who think that the logging system > > should be a completely generalized system for event generation and > > processing. I've shied away from using a word like "Event", preferring > > "LogRecord" which tries to indicate that this is a focused class for a > > specific job. > > You will find in almost every major software system that events are > generated, filtered and dispatched. I don't see the a problem if a > logging module would live to these realities. Just because unix/sysloging If it's a beneficial side effect you get for free, fine. If it imposes additional work for the simplest case, not so fine. > or other software has evolved with string/severity-logging doesn't > make it todays choice. IMO python's ease of working with classes/types > *makes* a difference. Yes, but you are missing the point that you *can* have flexibility of classe s/types etc., and in my last post I just gave one example of how it could be done. I'd prefer if you gave a specific critique of the approach I suggested, indicating why it wouldn't work. For example, a particular problem you are trying to solve which you just can't, with the existing functionality or that proposed in my last post. > In distributed transaction systems logging even provides some > ACID-guarantees as it is used for driving the 2PC-protocol. > Think about it a minute. I don't say that python's logging must > do this in the standard lib. Okay, we've got some common ground here. I am not for a minute arguing that the functionality you want is somehow "wrong". It's all a question of what goes in the standard lib - at least for now, with the 2.3 release date approaching. That's my focus, it probably makes me look a bit slow-witted. > I appreciate your efforts but still disagree with your design decisions. > This should not prevent us to make a break discussing these issues. Holger, I'm sorry if you're losing patience with me. As my wife is often telling me, sometimes I just don't get it ;-( Thanks for your patience so far, Vinay _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4