Re: Using logging module for conditional nested logs
On Nov 4, 11:14 pm, Reckoner wrote: > Thanks again. You're welcome. You asked (on a Logging 101 blog comment) for a tutorial on how to use Filters. I can point you this Stack Overflow question: http://stackoverflow.com/questions/1383254/logging-streamhandler-and-standard-streams The answer is perhaps the tutorial you asked for. Another example is given in this test script: http://opensolaris.org/sc/src/xen-gate/xvm-3.3+xen.hg/tools/python/logging/logging-0.4.9.2/test/log_test18.py Hope it helps. Regards, Vinay Sajip -- http://mail.python.org/mailman/listinfo/python-list
Re: Using logging module for conditional nested logs
On Nov 4, 1:30 pm, Vinay Sajip wrote: > On Nov 4, 7:40 pm, Reckoner wrote: > > > > > I hope that made some sense. > > Not especially :-( > > Sorry I don't understand exactly what you mean, because I find your > terminology confusing. For example, "logger that is attached to foo2" > - loggers are not attached to functions. "It responds to the 'root' > logger" - what responds? What's meant by "respond"? > > Loggers correspond to specific code components in an application. > Normally these areas are modules and sometimes they're classes. > > You can certainly treat functions as areas but this will typically > become unwieldy in any sizeable application. It doesn't (in general) > make sense to have a specific logger for foo1 for use only when it's > called by foo2. These seem like anti-patterns to me. > > Handlers are attached to loggers to make events logged via those > loggers available to different audiences - via console, file, email > etc. > > If you want to log that foo1 is being called by foo2, you can do this. > For example, you could have a utility function which walks (a > sufficient part of) the call stack to see the function call hierarchy, > then log this as additional information (e.g. using the 'extra' > parameter to the logging call). You can attach Filters to loggers and > handlers which use this information to decide where and whether to > actually record the event. > > As well as the Python logging documentation, you may also find the > following link useful: > > http://plumberjack.blogspot.com/2009/09/python-logging-101.html > > Regards, > > Vinay Sajip I appreciate your patience, as I am new to this. Your comments have put me on the right track. I will look at the link you specify. Thanks again. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using logging module for conditional nested logs
On Nov 4, 7:40 pm, Reckoner wrote: > > I hope that made some sense. Not especially :-( Sorry I don't understand exactly what you mean, because I find your terminology confusing. For example, "logger that is attached to foo2" - loggers are not attached to functions. "It responds to the 'root' logger" - what responds? What's meant by "respond"? Loggers correspond to specific code components in an application. Normally these areas are modules and sometimes they're classes. You can certainly treat functions as areas but this will typically become unwieldy in any sizeable application. It doesn't (in general) make sense to have a specific logger for foo1 for use only when it's called by foo2. These seem like anti-patterns to me. Handlers are attached to loggers to make events logged via those loggers available to different audiences - via console, file, email etc. If you want to log that foo1 is being called by foo2, you can do this. For example, you could have a utility function which walks (a sufficient part of) the call stack to see the function call hierarchy, then log this as additional information (e.g. using the 'extra' parameter to the logging call). You can attach Filters to loggers and handlers which use this information to decide where and whether to actually record the event. As well as the Python logging documentation, you may also find the following link useful: http://plumberjack.blogspot.com/2009/09/python-logging-101.html Regards, Vinay Sajip -- http://mail.python.org/mailman/listinfo/python-list
