Skip,
Thanks for the detailed post indicating what stuff you find useful, and what
stuff you don't need. It seems that your use case is fairly unusual, so I
completely understand that you have optimized how you use logging. I will
consider how to try to incorporate your feedback without breaking b
>> If the user doesn't need those values and can provide cheap
>> substitutes, perhaps their computation can be avoided. I did that
>> recently by inlining only the parts of logging.LogRecord.__init__ in
>> a subclass and avoided calling logging.LogRecord.__init__ altogether.
> If the user doesn't need those values and can provide cheap substitutes,
> perhaps their computation can be avoided. I did that recently by inlining
> only the parts of logging.LogRecord.__init__ in a subclass and avoided
> calling logging.LogRecord.__init__ altogether. It generated lots of
> i
Thomas Heller python.net> writes:
> > by the logging package itself:
> >
> > nameName of the logger
> > levelno Numeric logging level for the message (DEBUG, INFO,
> > WARNING, ERROR, CRITICAL)
> [and so on].
>
> Shouldn't this list be documented? Or is it?
T
Vinay Sajip <[EMAIL PROTECTED]> writes:
> The existing fields which could be overwritten are ones which have been
> computed
> by the logging package itself:
>
> nameName of the logger
> levelno Numeric logging level for the message (DEBUG, INFO,
> WARNING, ERR
Vinay> I couldn't think of a good reason why it should be possible to
Vinay> overwrite these values with values from a user-supplied
Vinay> dictionary, other than to spoof log entries in some way.
If the user doesn't need those values and can provide cheap substitutes,
perhaps their
Guido van Rossum 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
