[Python-Dev] PEP282 and the warnings framework

[Vinay Sajip]

[Vinay]
> > 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,
[Walter]
> But you have the same problem with Logger, which is made to be
> subclassed. And Logger probably changes more often than LogRecord.

Not necessarily. LogRecord is a grab-bag for attributes, I expect more
volatility in LogRecord attributes (in the sense that even if I only make a
similar number of attribute changes to LogRecord and to Logger, I would
expect may more changes by users to LogRecord than to Logger - or at least,
I wouldn't be surprised if that were the case).

[Vinay]
> >
> > 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.
[Walter]
> 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.

It's not necessarily a bad smell. It's analogous to the "inheritance or
composition?" question. There are many cases where designers wrongly use
inheritance where composition will suffice.

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

Yes - a minor variation.

[Vinay]
> > 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.
[Walter]
> 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.

Yes, but focused for what job? Names *can* be important. I've committed my
share of naming boo-boos in the past, and no doubt will in the future. But
Event, even when qualified with "logging.",  signifies to me a more general
construct (e.g. used for more general messaging applications) than a
"LogRecord" (used for holding information about a specific error/diagnostic
logging event). I suppose LogEvent would be OK, too - I think I just picked
LogRecord to echo the PEP.

Regards,

Vinay




_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com