[Python-Dev] PEP282 and the warnings framework

holger krekel pyth@devel.trillke.net
Fri, 17 May 2002 22:06:20 +0200


[trying to strip the discussion down]
Vinay Sajip wrote:
> > this is an interesting point. LogRecord is the basic unit of the current
> logging.
> > But you can not pass customized (subclassed) LogRecords without them
> > beeing wrapped (read: contained) in another LogRecord instance. Thus
> > you have to e.g. access 'record.msg' in filters.  Why two instances
> > where one is enough, more flexible and pretty straightforward?
> 
> There aren't two instances. 

and 

> ...
> Next question: how to pass in this information? two choices spring to mind:
> 
> 1. Use a keyword argument, extra_info=None. (...) A passed in
> value would become the extra_info attribute of the LogRecord.
> 
> 2. Use the "msg" parameter, which all logging calls already have (...)
>    it can be used by user-derived classes, which will find it in the msg attribute
>    of the LogRecord.

are not very consistent statements <wink>.

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

You will find in almost every major software system that events are
generated, filtered and dispatched. I don't see the a problem if a
logging module would live to these realities. Just because unix/sysloging 
or other software has evolved with string/severity-logging doesn't
make it todays choice. IMO python's ease of working with classes/types
*makes* a difference.

In distributed transaction systems logging even provides some 
ACID-guarantees as it is used for driving the 2PC-protocol. 
Think about it a minute.  I don't say that python's logging must 
do this in the standard lib. But arguing with 'syslog' or 'log4j' 
seems to be a quite narrow view.

I appreciate your efforts but still disagree with your design decisions.
This should not prevent us to make a break discussing these issues.
Everybody (including us) has probably heard enough arguments.

regards & thanks,

    holger