Vinay Sajip wrote:
> [Steve]
> > I think your previous example showed that subject-level
> > filtering required a separate logger/channel per subject.
> > Is there another mechanism for subject tracking?
>
> Yes, you can use Filters. Attach one or more Filter instances to the root
> logger and they can allow selective processing of certain events, based on
> any criteria you choose. The Filter implements a method which is called with
> a LogRecord. In my system, the LogRecord is analogous to what you term an
> Event.
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?
In addition you cannot currently do *early* filtering based
on anything else than 'severity'. I find that strange considering
that the logging-api would hardly loose its convenience (warn/error/...)
if you made LogRecord or better logging.Event the basic working unit.
Early severity checking could still be done in these methods. The
log-method though should work with Events & subjects (and a default
factory if the first object isn't already an Event).
This is by no means a complete concept but i think it's worthwhile
to consider.
have fun,
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