Antoine Pitrou added the comment: Hi Vinay,
Thanks for your reply. I think it's important to rephrase the problem in a simple way. The basic pattern is that there is a class C (say, a TCP connection class) where a specific part of each log line should from an instance-specific "contextual string" (say, an IP address). Given the current logging API, this means each instance of C will want either a separate Logger object, or a separate Formatter object, or a separate LogRecord subclass, etc. Now the problem is: 1. creating a separate Logger object per instance of C leads to memory leaks 2. creating a separate Formatter, Filter etc. does not work because the shared logger (whatever it is) has no means to decide which Formatter or Filter instance it should use depending on the caller (perhaps I'm wrong about this one? explanations welcome :-)) 3. creating thread-local objects (e.g. Formatters), not only is a quite ugly solution IMO, but it doesn't suit every situation. For example, if you use an event loop (asyncore, Twisted), all objects will live in the same thread yet require distinct Formatters. So the only mildly satisfying solution right now is: 4. create a specific Logger class wrapper which will require the caller to pass its "contextual string" to them so that the wrapper has the appropriate context information. This does almost the right thing (except for one supplementary parameter for each logging call), but is still a bit of code to type and get right. Now to make it easier for the developer I see two solutions: A. enhance the logging module with an API to create non-persistent loggers. That's what I was originally proposing to work on. B. provide a generic implementation of the afore-mentioned wrapper (see solution 4), ready to use for the most common purposes. Basically, the generic wrapper would be instantiated with a pattern (say : "1.2.3.4: %(msg)s") which would be used to modify the msg for each logger call I'd be willing to implement either of those two solutions, depending on which we decide is better :-) What do you think? ____________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue932563> ____________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
