[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4