[snip]
>
> Yes. PEP282/logging.py offers these mechanisms. Logger
> channels offer
> subject-area filtering, levels offer severity filtering, and
> filters offer
> pretty much anything you want in terms of flexibility.
>
How does a "channel" offer subject area filtering?
How do I get a single log with some subjects enabled
and some subjects disabled?
[snip]
>
> Yes, and developers who use logging should, for large
> applications, devote
> the same energy to ensuring that their logging design is in
> keeping with the
> complexity of their application. After all, logging is a kind
> of
> instrumentation.
Actually it is more than this. Much more.
The deal is that most applications are driven by events.
For trivial "read/filter/write" applications, the events
are hardly worth describing as unique objects. For almost
everything else, however, the events are the core of the
application's work.
If the logger uses an extensible "Event" class as the
root of its work, then an event-driven application can
simply log events; a filter and formatter can selectively
display
them. The filter can be initialized with runtime parameters to
allow flexible debugging.
Since each Event instance can carry a severity code, the filter
can use this information instead (or in addition to) the
subject.
Since Python is so flexible, a well-designed logger can tolerate
Strings instead of Event instances and work well with those,
also. Strings, however, would require additional parameters
(or method names) for severity, subject, timestamp, etc.
For example, a commonly-used subclass of the logger would log
Exception and Error instances. The class information would
indicate the severity in an obvious way.
>
> > My vote is:
> > A) existing exception/error hierarchy
> > B) LogEvent class with message string, subject string,
> delayed
> > introspection, automatic timestamping. LogEventObject and
> > LogEventEnviron subclasses would drag around additional
> details.
> > C) The logger would filter LogEvents based on subject
> string.
> > Since each event is an object, the logger could simply
> pickle
> > the events, or write their __str__ to stderr.
>
[snip]
A) Keep separate log events from the exception/error hierarchy.
However, the a subclass of the standard logger should gracefully
accept instances of Error or Exception and log them
B) I'm lobbying for an Event or LogEvent class to allow an
an application to work with events as first-class objects,
especially if this becomes core to the Python library.
=====
--
S. Lott, CCP :-{)
S_LOTT@YAHOO.COM
http://www.mindspring.com/~slott1
Buccaneer #468: KaDiMa
Macintosh user: drinking upstream from the herd.
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
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