[Python-Dev] Proposed additional keyword argument in logging calls

[Guido van Rossum]

On 11/22/05, Vinay Sajip <vinay_sajip at red-dove.com> 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/)