[py-dev] py.log and multiple keywords

holger krekel hpk at trillke.net
Mon Jun 20 17:32:03 CEST 2005


Hi Grig!

[Grig]
> [holger]
> > So it seems that with the simple ability to associate functions
> > to keywords you can basically do a lot of stuff without knowing 
> > any big API or intricate details. 
>
> I see your point. It's still somehow convoluted to achieve my goal
> using  the solution you give, but on the other hand I understand that
> you want to keep the API 'lean and mean'. 

I basically think that application should be left free to define
it's logging structure and semantics. The 'multilogger' example
i gave makes it more obvious user what the semantics of closing/opening 
files etc.pp. are.  It's really simple code and i bet faster 
to write than understanding and tweaking the logging module's structure. 

> I still haven't figured out what a practical application of the current
> semantics for multiple keywords would be -- can you give an example? I
> noticed you changed the _getconsumer function to first match on the
> whole multiple keyword tuple, and then on  prefixes of the tuple.

I have used it the following way so far: 

    # -- 'somefile.py': 

    import py

    log = py.log.Producer("somefile") 
    py.log.setconsumer("somefile", None)  # route all logging to /dev/null 

    def dispatch(x): 
        log.dispatch(x) 

    def send(host, arg): 
        log.send(arg, "to", host) 

    # -- 'test_somefile.py' 
    import py

    py.log.setconsumer("somefile", py.log.STDOUT)  # show more info for failing tests
    py.log.setconsumer("somefile send", None)  # don't show dispatching, though

    ... 
    # -- end files 

So not only can you come up with new ad-hoc categories but you 
can have fine-grained view control from remote places.  You can for 
example, have a different logging view from a main cmdline entrypoint
than from the tests etc.pp.  In this view, the distinction between
'debug' and 'info' etc.pp. depends on the perspective and is 
not a static property of the source code.

IMO this lets one use py.log.Producer's much like print statements
but the effort of writing down those "print" info is then not lost 
but put to productive use. 

cheers, 

    holger


More information about the py-dev mailing list