[Python-Dev] PEP282 and the warnings framework

[Vinay Sajip]

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

> The point here is that subjects can (and often are) as
> fine-grained as individual methods of a class.  Sometimes
> they are even more fine-grained when dealing with fairly
> complex algorithms, although this is rare.
>
> When I need fine-grained subjects management, I don't want
> to have many logger/channel instances.  I want to have one
> channel with a subject attached to each loggable Event.

Then you can do...

logger = logging.getLogger("")    #root logger

logger.log(logging.INFO, "subject 1", ...)
logger.log(logging.WARN, "subject 2", ...)

etc.

A filter can process these events:

class SubjectFilter(Filter):
    def filter(self, record):
        if record.msg == "subject 1":
            ...
        elif record.msg == "subject 2":
            ...

My example's a bit crude, but you get the picture.

> [Vinay]
> > I understand why some people might like this, but I don't
> > think it's
> > everyone's preferred way of working. The successful logging
> > systems which
> > inspired PEP282 do not force one to instantiate a class for
> > the simple case.
> > My other posts indicate how some support for your needs might
> > be provided,
> > without forcing everyone down the same path.
[Steve]
> Agreed.  My position is that an Event instance should be
> created, even when someone uses the convenience methods
> available under PEP282.  The core function is to track
> Events; even when done through convenience functions that
> make it appear as though logging is simply tracking a string.

This is what happens now, except that the class is called LogRecord rather
than Event.

> Agreed, loggable Events are not Exceptions, but the information
> in a loggable Event would be derived from the attributes
> of an Exception

This is what happens now, except that in the default case, the logging
system calls sys.exc_info() automatically when it knows it is called in the
context of an exception. The web page has more details:
http://www.red-dove.com/python_logging.html

The distribution also has numerous examples of logging exceptions.

> The constructor for a loggable Event would accept an
> Exception as an argument and create a new loggable Event
> from the Exception's attributes.

This is not exactly how it happens, but the effect is analogous. Currently,
the LogRecord constructor is not exposed to users (since it was meant as an
internal class); this may change in the future.

> [Vinay]
> > "Filling in subject and severity automatically" -
> > I can just see
> > a plethora of disagreeing views over what severity should be
> > used for this
> > exception or that.
[Steve]
> Precisely the point - severity is a difficult concept, not
> core to the way logging works.  It is only one of the many

My point wasn't that severity is a difficult concept, just that answers to
the question "How important?" are very often subjective. It may be that in a
given scenario no two developers agree, and neither is wrong. The difficulty
is in the subjectivity of the severity :-)

> attibutes of a loggable Event; the primary purpose of logging
> is to accept Events, filtering them and pickling them for
> future analysis.
> The pickling can be by formatting for printing or by storage
> to some other file system or RDBMS (or broadcasting through
> a network or whatever).

The logging.py distribution has many examples of this.

Regards

Vinay


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