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

[Grig Gheorghiu]

Forgot to CC the list again...

Hi, Holger

--- holger krekel <hpk at trillke.net> wrote:

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

I don't mind at all if you refactor and simplify things. I haven't done
much work on it since my last commit. You're probably right about not
needing severity levels right away. I agree with you that we should
look at things from an 'end-user' point of view and thus make the calls
to the py.log functionality as simple and natural as possible.

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

Yeah, it would be nice to have the 'batch email' functionality. I don't
think the logging module offers any distinction between single email
messages and batch mode.

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

Haven't had time to do this yet....

Grig