|
From: Kevin A. <al...@se...> - 2001-12-13 19:57:02
|
> > 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 I like the idea of being more specific, and it could probably be done by passing in some more information such as the __file__ and self and other variables if we wanted to be able to identify the class and instance where the error occurred, etc. > > 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. Sorry, I'm referring to just the self.log as a way of hiding the longer log.Log.getInstance().info( " interval is up..." ) The shorthand self.log won't work because that assumes you have a reference already. > 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. Okay, we need to experiment and get the right trade-off between informative and too verbose. I'm mostly interested in this for debugging and unit test purposes. If I can start using a simple log statement in place of a print statement and not have to worry about slowing down the code too much that will be very helpful. I've gotten out of the habit of redirecting the output to the shell, but I want to start doing that as well while I'm debugging. > > 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. If we use this code, then we definitely need to include it with the distribution. It is probably overkill for our needs, but I'll try and take a look at it in the next few days. I still like the idea of just referencing functions in the log module and I think I'll go ahead and try that out. Then you could just do: import log log.info(" interval is up...") since info would be setup to do the right thing. ka |