Re: [Pythoncard-users] logging revisited

Kevin Altis wrote:

> I brought up the singleton issue because I decided I wanted to start using
> logging on a more regular basis rather than adding and then
> removing/commenting print statements all over the place, which is my typical
> messy solution. I started to look at the Log class which I hadn't used in a
> while and decided the log.Log.getInstance() syntax was a bit awkward. Here's
> an example from some of Jeff's code:
> 
>         log.Log.getInstance().warning("WidgetLoader.installEventBindings: "
> +
>                                       "no event bindings at all: " +
>                                       moduleName)


> The worldclock.py sample syntax is cleaner, but that is because it keeps a
> reference to the instance:
> 
>         # Enable logging
>         self.log = Log.getInstance()
>         # self.log.enable()
>         # Normally we enable only ERROR and WARNING messages
>         self.log.enableLevels( [ Log.ERROR, Log.WARNING, Log.DEBUG,
> Log.INFO ] )
>         ...
>         self.log.info( " interval is up..." )


This is a pretty clean way of using log.  If we move to a logging 
framework that allows categories, like log4py, then you could do this:

     self.log = Log.createCategory( "WorldClock" )

Then use it:

     self.log.info( "interval is up..." )

And get output something like this:

     WorldClock | INFO | interval is


> 
> That won't work for log statements we want to scatter throughout the
> framework. Remember that the logging level and whether a log file is
> generated can be set, so the log statements shouldn't burden normal
> execution of an application or produce any output unless requested.


I'm missing the point about why this won't work for log statements 
scattered throughout the framework.  The log statements won't do 
anything if logging is disabled.

Using log4py would give us the added advantage of being able to create 
categories at the module ( "Resource" ) and object ( "Widget", 
"EventQueue" ) level, so the output could be much more informative.


> This seems like a good time to revisit the logging issue as we standardize
> our singleton class. There should be much more diagnostic output in the
> framework, but I would like to pick a longer-term solution before starting
> to add log statements throughout the code.
> 
> Could we just have a variable in the module file such as:
> 
> log = Log.getInstance()
> and then use
> from PythonCardPrototype.log import log
> That seems like it should work.
> 
> Does anyone have suggestions or feature requests for our logging classes?
> Are there any "standard" Python logging solutions I'm overlooking? I found
> log4p (based on log4j at SF
> http://sourceforge.net/projects/log4p/
> http://log4p.sourceforge.net/
> but no files have been released yet.


Check out http://www.its4you.at/log4py.php

The code is hosted on sourceforge.


> 
> ka
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> 
> 



-- 
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
    quoted in the book
    A Word a Day