[py-dev] Logging in the py library

[Grig Gheorghiu]

Hi, Holger

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

> Hey Grig, 
> 
> On Fri, Jun 10, 2005 at 16:09 -0700, Grig Gheorghiu wrote:
> > I just svn commit-ed 2 files: misc/log.py and
> misc/testing/test_log.py.
> > I tried to keep things as simple as possible and as close to the
> spirit
> > of py.trace as possible, while using the logging module as the
> > back-end. Please consider this experimental code. I'll be working
> on it
> > throughout the weekend. 
> > 
> > Comments/suggestions are very welcome, vital actually :-)
> 
> first of all, thanks for helping!  It looks nice so far 
> yet i am giving you detailed feedback and criticism
> as requested.  And please, you don't need to excuse 
> yourself for anything.  This is a technical discussion :-) 
> 
> - we should merge the py.trace and py.log namespaces  
>   e.g. by saying that all non-underscore and/or all lowercase 
>   names are keywords and the rest are functions/classes, e.g. 
> 
>     py.log.debug("hello world")   # as current py.trace.* 
>     py.log.set_logger('debug', py.log.FileLogger(path, append=True))
> 
>   and maybe forget about the [...] and getitem-trick alltogether. 
>   Keyword arguments provide nice flexibility for future features
>   which __getitem__ can't. 
> 
>   Note that 'set_logger' and 'FileLogger' would not be regarded as 
>   a keyword because they contain underscores and are not all
> lowercase. 
> 
>   We may want to consider to keep the FileLogger() and similar 
>   names very close to the logging module.  But please don't 
>   expose the Logging module's classes directly but just
>   delegate to them underlyingly. 
> 
> - it seems you prefer the 'py.log' naming.  I am fine with that. 

I didn't intend to replace py.trace with py.log. I was thinking that
there would be 2 orthogonal name spaces: py.trace for specifying the
messages/keywords to be logged, and py.log for choosing the
loggers/filters/etc. One could specify a py.log logger at run-time via
a configuration file, whereas the py.trace stuff would be pretty much
self-contained and 'set in stone'.

But I have no problem with merging the 2 namespaces. I'll give that a
shot.

> 
> - make sure that all your files have the 'svn:eol-style'
>   property set to 'native' with e.g. 
> 
>       svn propset 'svn:eol-style' native FILE1 FILE2" 
> 

No problem. I wanted to do a 'dos2unix' on the files before I checked
them in, but I forgot...

> - it should always be easy for an application to completely 
>   take over logging (as the current py.trace allows) and not
>   care about custom loggers or even hierachies. So something
>   like 
> 
>     def myfunction(message): 
>         ... 
>     py.log.set_logger("", myfunction) 
> 
>   should be enough to have all messages routed through 
>   my function. 
> 
> - for writing tests, please don't just create random   
>   files here and there.  Use something like: 
> 
>     dir = py.test.ensuretemp("logtest") 
>     p = dir.join('py_stdout') 
> 
>   and make sure that such paths can always be passed to 
>   py.log functions and classes, e.g. by str()ing path-arguments 
>   them early. 

Got it.

> 
> - please keep the basic py.trace functionality (renamed to 
>   py.log to your likening) self-contained and put the extra 
>   stuff (like FileLogger etc.pp) into a log_support.py file.  
>   I'd really like to use the basic mechanism from py.execnet 
>   very early on. 

OK, will do, if you want to merge py.trace and py.log.

> 
> - i reserve the right to tweak the final exact names 
>   because i really want the py lib to have a tight concise 
>   namespace organization.  So for example. 
> 
>     py.log.File(...) might be preferable to the duplication in 
>     py.log.FileLogger(...) 
> 
>   from my anal naming point of view :-) 

No problem. You're the keeper of the keys :-)

Thanks for the comments/suggestions. As you see, I have much to learn,
and working on the py lib provides the perfect opportunity.

Grig