[py-dev] refactoring py.log ...

[holger krekel]

Hi Grig, 

On Tue, Jun 14, 2005 at 16:10 -0700, Grig Gheorghiu wrote:
> --- holger krekel <hpk at trillke.net> wrote:
> > Doesn't the logging module offer the underlying output/formatting
> > logic in a more raw form, maybe?  Or else, isn't the logic needed for
> > File, Stdout and Stderr trivial to implement?  We then probably
> > don't need to bother with the logging module at all. 
> 
> I'll look into using more low-level functions/classes from the logging
> module. As far as implementing its functionality from scratch: at least
> for File/Stdout/Stderr it wouldn't be very hard to do, but then we'd
> need to worry about thread safety etc., which are issues that the
> logging module takes care for you. Plus the whole mechanism of
> registering various handlers for various severity levels is pretty
> nice,  although again it wouldn't be that hard to mimic.

Yes, i now even think that reusing the logging module at API level 
might not be such a good idea.   Reusing some code and ideas by 
copy-and-paste may just be enough.  It's no dark magic that is
changing everyday. 

Moreover, I am really beginning to come from the usage
side and i feel that i don't really want severity-distinctions
statically everywhere in the source code although it may seem
natural at first. (see my example in an earlier mail). 

I guess i am at the verge of wanting to follow a more radical
keyword/tag based approach.  Would you mind if i refactor 
and simplify things accordingly?  It's possible that we
introduce some default severity levels but i'd like to
postpone it until there is a real need. 

> > Btw, I don't know how the logging's email backend works but there
> > probably is some "commit()" like function that actually
> > triggers sending a mail, or not? I probably don't want an email
> > message on each logging entry :-)
> 
> My understanding is that it DOES send an email per log entry :-(, but I
> haven't tinkered with the SMTP logging backend that much yet. 

This may point to an interesting problem.  Logging backends/consumers
are not really stateless.  For example, traditionally in Unix
the sysloggers have two modes of writing to files, one that
commits ('fsync()') and one that doesn't.  The latter is
faster but log entries may get lost if there is a crash (even
a minute old entries).  Or does the logging module offer this
distinction?  Anyway, it's just a few lines of code and it's
ok if we do it ourselves (and test it accordingly). 

Sending batched log entries is a use case where we
probably could do something simple, e.g. 

    l = []
    py.log.set_logger('default', l.append)
    call_program() # logs various stuff
    for msg in l: 
        if 'error' in msg.keywords: 
            # send an email with a selection of messages 

IOW, we don't even neccessarily need a custom Email logger 
and introduce names and API design for it. 

> I'll be playing with it, as well as the Syslog and WinEvent
> stuff, and I'll let you know what I find.

that would be useful. 

cheers, 

    holger