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

[Vinay Sajip]

Guido van Rossum <guido <at> python.org> writes:
> 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.

OK.

> 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.

The existing fields which could be overwritten are ones which have been computed
by the logging package itself:

name            Name of the logger
levelno         Numeric logging level for the message (DEBUG, INFO,
                WARNING, ERROR, CRITICAL)
levelname       Text logging level for the message ("DEBUG", "INFO",
                "WARNING", "ERROR", "CRITICAL")
msg             The message passed in the logging call
args            The additional args passed in the logging call
exc_info        Exception information (from sys.exc_info())
exc_text        Exception text (cached for use by multiple handlers)
pathname        Full pathname of the source file where the logging call
                was issued (if available)
filename        Filename portion of pathname
module          Module (name portion of filename)
lineno          Source line number where the logging call was issued
                (if available)
created         Time when the LogRecord was created (time.time()
                return value)
msecs           Millisecond portion of the creation time
relativeCreated Time in milliseconds when the LogRecord was created,
                relative to the time the logging module was loaded
                (typically at application startup time)
thread          Thread ID (if available)
process         Process ID (if available)
message         The result of record.getMessage(), computed just as
                the record is emitted

I couldn't think of a good reason why it should be possible to overwrite these
values with values from a user-supplied dictionary, other than to spoof log
entries in some way. The intention is to stop a user accidentally overwriting
one of the above attributes.

But thinking about "Errors should never pass silently", I propose that an
exception (KeyError seems most appropriate, though here it would be because a
key was present rather than absent) be thrown if one of the above attribute
names is supplied as a key in the user-supplied dict.

> Perhaps it makes sense to call it 'extra' instead of 'extra_info'?

Fine - 'extra' it will be.

> As a new feature it should definitely not go into 2.4; but I don't see
> how it could break existing code.
>

OK - thanks for the feedback.

Regards,

Vinay Sajip