[py-dev] What's next for py.log?

[Grig Gheorghiu]

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

> Hi Grig, 
> 
> On Tue, Jun 21, 2005 at 07:54 -0700, Grig Gheorghiu wrote:
> > Do you think the core consumer and producer code will remain as is
> for
> > py.log? 
> 
> I currently guess so, yes.  I still feel there will be some
> re-thinking
> after more people have used it more.  Especially i think that the 
> dispatching rules (how keywords are connected to consumers) will
> have to become more flexible at some point.  Hum, coming to think
> of it we might want to change 'setconsumer' into 'subscribe' 
> and offer a way to specify if a subscriber will consume a message 
> or just look at it.  This may also help with your multilogger 
> use case. (Also see below for an example). 
> 
> > It seems to work pretty well. I might still sub-class the
> > Producer class for my multiple-keyword needs -- but that can easily
> be
> > done in my application code, without changing py.log itself.
> 
> Right.  
> 
> > Are you thinking about adding more consumer objects such as syslog,
> > email, Win Events? If so, I can give some of them a shot.
> 
> syslog and win-events would probably be interesting whereas
> email has IMO too custom needs to warrant caring for it in the
> py lib at the moment.  For syslog, i think it is easiest and most
> flexibel to just offer a py.log.Syslogger class: 
> 
>     class Syslog(...): 
>         def __init__(self, facility, severity, prefix=""): 
>             ... 
>         def __call__(self, msg): 
>             # send to syslog daemon, take minimal code from
>             # logging module 
> 
> and then in application code one can do: 
> 
>     py.log.subscribe("* error", 
>                      Syslog("user", "error", "myprog: "), 
>                      consume=False)
> 
> so that all messages with an 'error' keyword in it would show up
> in syslog.  This is an application of the 'subscribe' extension idea 
> above in that you can 
> 
> a) have '*' meaning an arbitrary number of keywords 
> 
> b) consume=False means that this subscription will not consume 
>    the message and other possible subscribers should still get 
>    invoked for the same message 
> 

One more thing: I found it necessary in some of my application code to
set a consumer function that takes more than one argument. So I ended
up doing something like this:

def __call__(self, *args, **kwargs):
    func = self._getconsumer(self.keywords):
    if func is not None:
        return func(self.Message(self.keywords, args), **kwargs)

Maybe we can add this to the current svn version. In my case, the
function was a http POST function that took the message as the first
argument and the CGI script to post to as the second argument. 

Grig