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

Maybe set_subscriber? Because the method belongs to the Producer class,
and the consumers are the ones that subscribe, 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 

I like the idea of having a consume flag. This will indeed make life
easier for me in regards to my multi-logger use case.

> 
> > I'm also thinking about advertising py.log a little on my blog. Or
> > should I refrain until the py release? Let me know what you think.
> 
> That would be great.  Personally, i feel that the exact API and 
> especially the dispatching mechanisms will change a bit, though, 
> considering the open questions from the above 'subscribe' idea. 
> So it depends a bit. If you plan to introduce py.log then it is 
> probably too early.  If you want to discuss and mention the ideas 
> including examples a bit, it's a perfect time. 

OK, will do. I'll talk about keyword-based logging and give some
examples, with strong caveats that the syntax might change.

Thanks,

Grig