[Dev] logging proposal

[Kapil Thangavelu]

On Mon, 2004-09-13 at 15:29, John Anderson wrote:
> Hi Everyone:
> 
> I looked over the logging proposal. I have a few personal biases on 
> logging, which may be somewhat controversal, and consequently you may 
> want to ignore some of my suggestion.
>

i can sympathize with strongly held beliefs, besides constructive
arguments between differing view points are way more
productive/insightful than passive agreement ;-)

> 
> I find that adding lots of logging makes my code bigger that it needs to 
> be, makes the code look ugly, slows it's execution and I often have a 
> hard time wading through long logs, so as a rule I only do very minimal 
> logging.
> 

just to be clear, i'm not advocating additional logging, just use of
enough framework to make what is there more effective.

as a developer, i normally get 3 tools when approaching a new code base,
a debugger, logging, and unit tests. unfortunately the larger the code
base the less effective the debugging and unit tests are unless you can
pinpoint the issue and work identify the call stack. to that end i find
logging to be very useful to understanding larger code bases. completely
ot, but i'm also in the process of porting wing to linux ppc.


> That said, I prefer a syngax that allows me to log something by adding 
> the mininmum number of lines of code, and even the python syntax for 
> logging seems a little too heavyweight for my tastes. I suspect that's 
> why we end up with people using print instead of logging. However, I 
> feel strongly that we should never be using printf and use logging 
> instead, which makes it possible to turn on/off filter redirect etc.
> 

hmm.. minus the initial setup and config, using the logging framework
vs. using print statements is fairly equivalent afaics.. ie

  log.debug("some statement %s %r", foo, bar) # even get to use printf
style ;-)
  print "some statement", foo, bar
  print "some statement %s %r"%(foo, bar)
  log.info("some statement %s %r%(foo,bar))

  

> I find it hard to come up with a sensable logging hiearchy, so if it 
> were up to me, I'd probably leave it optional and just use a default, 
> like file name paths or something else that's very simple. I generally 
> find that there are  more levels of logging that I ever need, so keeping 
> them to a very minimal set would be my preference.
> 

its not clear if by logging levels you meant different channels/logger
paths, or different levels (ie warn, debug, etc.) i'll assume the
former, as the latter are generally constant at 4.

i've done automation of the hierarchy based on sys.modules path before,
it works okay but imho a bit lame for deeply nested hierarchies/larg
systems, which chandler amounts to. some normalization and hierarchy
collaspe would be useful i think.

ie these would be some of the autogenerated logger names from
sys.modules

osaf.contentmodel.contacts.Contacts
osaf.framework.attributeEditors.attributeEditors

hmm.. actually it doesnt look so bad, and giving folks the option to
give an explicit name would still be there. it would be even nicer with
a normalized parcel hierarchy (ie model/code/views for a semantic parcel
located in an actual parcel). i'd still prefer something shorter/human
generated as it makes for easier log reading. ala

model.contacts
framework.attr-editor

or 

osaf.contacts
osaf.attr-editor
osaf.mail
repo.query


> Finally, if possible, I'd prefer a logging syntax with no more lines of 
> code than printf, with maybe the exception of an extra import at the top 
> of my Python file.

its basically two extra lines per module, the import and getting the
appropriate logger.

cheers,

-kapil

> 
> John
> 
> 
> Kapil Thangavelu wrote:
> 
> > hi folks,
> >
> > i put together a logging proposal, about unifying the logging  
> > configuration and usage within chandler,
> >
> > http://wiki.osafoundation.org/bin/view/Chandler/
> > AlternativeLoggingProposal
> >
> > the structure of the logging hierarchy is a big open question..
> >
> > cheers,
> >
> > Kapil Thangavelu <hazmat at objectrealms.net>       Vision Implemented
> > objectrealms.net <http://www.objectrealms.net>
> >
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> >
> > Open Source Applications Foundation "Dev" mailing list
> > http://lists.osafoundation.org/mailman/listinfo/dev
> 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev
-- 
Kapil Thangavelu <hazmat at objectrealms.net>       Vision Implemented
objectrealms.net <http://www.objectrealms.net>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.osafoundation.org/pipermail/dev/attachments/20040913/54f12921/attachment.bin