[py-dev] Logging in the py library

[holger krekel]

Hi Grig! 

On Mon, Jun 06, 2005 at 09:35 -0700, Grig Gheorghiu wrote:
> I think it would be useful to implement logging in the py library via
> the 'logging' module, which is supposed to be thread-safe. Currently
> there are one-off implementations of logging/tracing scattered across
> source files (for example the trace method in execnet/gateway.py). It
> would be nice to have a uniform way of capturing debug information with
> various levels of severity (debug, info, warning, error, critical). 

Adding Tracing/Logging to the py lib is definitely important. 
I'd like to hide the logging module under some nice 
super-simple API, though.  Or maybe not use the logging module 
at all or only optionally :-) 

I think that the severity categorization is not enough to make
nice use of logging information.  I don't have a fully fledged
idea but i think that having a keyword-based approach to
tracing would be more helpful.  Basically we could associate
with each logging message/object [*] a set of keywords.
severity categorizations would just be a keyword in that idea. 

Let me try an example for e.g. tracing in py/execnet/gateway.py: 

    import py  # this import is actually problematic to do in gateway.py, 
               # let's forget about that detail for the moment

    trace = py.trace.keywordtracer('execnet gateway') 

    class Gateway(object): 
        def __init__(self, ...): 
            trace("initializing gateway ...")
            ... 

'trace' may by default add a 'debug' keyword if called like this. 
If we want to print some warning, then we could do something like: 

    trace.warn("remote gateway side could not be destroyed") 

which would add the keyword 'warning' to that particular message.  

By default, everything would probably go to stdout but an
application should be able to redirect by keyword to specific
formatting/output backends (much like the logging module).  I
think it's important to allow this redirection to happen
_after_ the above example is already imported, so
redirections-by-keyword should be re-configurable at runtime. 

What do you think of this basic keyword idea?  (which cold
still use the logging module underneath for accessing all 
the backends if it makes sense). 

And sorry, but the py lib really aims at exploring
improvements over current ways of doing things :-) 

cheers, 

    holger


[*] one concern is how much overhead tracing adds to an application. 
    It should be possible to trace via objects (or lambdas/functions?, whatever) 
    that only produce a str() representation when there is a consumer
    for the tracing information.  In particular, if i "ground" the 'debug' 
    keyword to /dev/null then the tracing code should not spend time 
    str()ing objects.  I don't like the logging module's way of 
    turning messages into strings too early. So e.g. 

        trace.debug("gateway", gateway, "processes", message) 

    would not compute all the str()s of the objects if i (somehow) 
    set the debug keyword to 'ignore'.