I am getting started with your logging module and I went through the tutorial and know-how to create a top-level 'root' logger with the appropriate handlers.
I have a number of functions,say,
def foo1()
def foo2() ... foo1() # foo2 calls foo1
and I know how to connect each of these functions to the 'root' logger by doing something like
def foo1() logger = getLogger('root.foo1')
but I want to arrange it so that foo1 adds to the logfile that foo2 is using ONLY when foo2 calls foo1. In other words, if I do
def foo2() logger = getLogger('root.foo2')
or
def foo1() logger = getLogger('root.foo2.foo1')
it responds to the 'root' logger when I want it to respond to *any* logger that is attached to foo2.
Then, the question is how can I set up foo1 to log to whatever logger foo2 is using. The purpose of doing this is that I am interested in capturing when and by whom foo1 is called in whatever logger foo2 is using. So, if I attach a separate logger to a third function, say, foo3 (), then I can avoid reporting those instances when foo3 calls foo1.
On Nov 4, 7:40 pm, Reckoner <recko...@gmail.com> 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:
> On Nov 4, 7:40 pm, Reckoner <recko...@gmail.com> 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:
Reckoner wrote: > On Nov 4, 1:30 pm, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
>> On Nov 4, 7:40 pm, Reckoner <recko...@gmail.com> 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:
> 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.
_foo2Logger = None
def foo2(): global _foo2Logger _foo2Logger = whateverLogger foo1()
def foo1(): foo1Logger = logging.getLogger(_foo2Logger.name + '.foo1') # this is how you can "attach" dynamically a logger to another foo1Logger.info('')
But for all the reasons expressed by Vinay, you don't want to do that.
|
