On 11/22/05, Vinay Sajip <[EMAIL PROTECTED]> wrote: > On numerous occasions, requests have been made for the ability to easily add > user-defined data to logging events. For example, a multi-threaded server > application may want to output specific information to a particular server > thread (e.g. the identity of the client, specific protocol options for the > client connection, etc.) > > This is currently possible, but you have to subclass the Logger class and > override its makeRecord method to put custom attributes in the LogRecord. > These can then be output using a customised format string containing e.g. > "%(foo)s %(bar)d". The approach is usable but requires more work than > necessary. > > I'd like to propose a simpler way of achieving the same result, which > requires use of an additional optional keyword argument in logging calls. > The signature of the (internal) Logger._log method would change from > > def _log(self, level, msg, args, exc_info=None) > > to > > def _log(self, level, msg, args, exc_info=None, extra_info=None) > > The extra_info argument will be passed to Logger.makeRecord, whose signature > will change from > > def makeRecord(self, name, level, fn, lno, msg, args, exc_info): > > to > > def makeRecord(self, name, level, fn, lno, msg, args, exc_info, > extra_info) > > makeRecord will, after doing what it does now, use the extra_info argument > as follows: > > If type(extra_info) != types.DictType, it will be ignored. > > Otherwise, any entries in extra_info whose keys are not already in the > LogRecord's __dict__ will be added to the LogRecord's __dict__. > > Can anyone see any problems with this approach? If not, I propose to post > the approach on python-list and then if there are no strong objections, > check it in to the trunk. (Since it could break existing code, I'm assuming > (please correct me if I'm wrong) that it shouldn't go into the > release24-maint branch.)
This looks like a good clean solution to me. I agree with Paul Moore's suggestion that if extra_info is not None you should just go ahead and use it as a dict and let the errors propagate. What's the rationale for not letting it override existing fields? (There may be a good one, I just don't see it without turning on my thinking cap, which would cost extra. :-) Perhaps it makes sense to call it 'extra' instead of 'extra_info'? As a new feature it should definitely not go into 2.4; but I don't see how it could break existing code. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
