[Python-Dev] PEP282 and the warnings framework

[Walter Dörwald]

Vinay Sajip wrote:

> [...]
> 
> It might appear that allowing subclasses of LogRecord is the more natural
> thing to do. But this has the potential to stop me from extending
> LogRecord's functionality in the future, as some new attribute I introduce
> might conflict with the same-named attribute in some user's
> LogRecord-derived class. Since I want to preserve this freedom for myself
> and other maintainers of logging, 

But you have the same problem with Logger, which is made to be
subclassed. And Logger probably changes more often than LogRecord.

> the best option seems to be: allow another
> instance of an arbitrary class to hold whatever additional information the
> caller wants.
 >
> Next question: how to pass in this information? two choices spring to mind:
> 
> 1. Use a keyword argument, extra_info=None. You can use this on any call
> such as warn(), debug() etc. just as exc_info is currently used. A passed in
> value would become the extra_info attribute of the LogRecord.

This smells to much like extensibility to per-OO way, i.e. simple add a
void *user_data to every struct you have and you're done.

> 2. Use the "msg" parameter, which all logging calls already have, to have
> the semantics such that it is either a format string, or an instance such
> that str(msg) returns the desired format string. For the simple case, just
> pass in a string. For the more complex case, pass an instance - the caller
> can put any state in there that they want. It will not be used by the core
> logging module, except to call __str__() on it for the format string. But it
> can be used by user-derived classes, which will find it in the msg attribute
> of the LogRecord. This might seem "hackish" to some, but it's not really -
> it's just a question of packaging.

This is more or less the same as 1.: use an (additional) argument, that
will become an attribute of the LogRecord.

> [...]
> Slightly OT: There's a lot of people who think that the logging system
> should be a completely generalized system for event generation and
> processing. I've shied away from using a word like "Event", preferring
> "LogRecord" which tries to indicate that this is a focused class for a
> specific job.

Even if LogRecord was renamed Event, it would be a "focused class for a
specific job", because it would be logging.Event. But the name is not so
important as the functionality.

> [...]

Bye,
    Walter Dörwald