By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,407 Members | 1,753 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,407 IT Pros & Developers. It's quick & easy.

Invoker of a method

P: n/a
Hi Pythoneers

In an application I am developing I want to register the invoker of a
method call. Is there any way to find out who is invoking an object's
method? I do not want to rely on the caller telling the callee his name
explicitly.

thanks
Andre

--
Dr. Andre P. Meyer http://home.hccnet.nl/a.meyer/
TNO FEL Command & Control and Simulation, http://www.fel.tno.nl/div2/
Delft Cooperation on Intelligent Systems, http://www.decis.nl/
Jul 18 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Andre Meyer <me***@acm.org> wrote:
Hi Pythoneers

In an application I am developing I want to register the invoker of a
method call. Is there any way to find out who is invoking an object's
method? I do not want to rely on the caller telling the callee his name
explicitly.


inspect.currentframe lets you inspect the call frames up the stack,
including (of course) the caller's one; same as sys._getframe. However,
I suggest you reconsider using this in production code, as opposed to
debugging or other development-framework tasks. As the docstring says:

'''
This function should be used for internal and specialized purposes only.
'''

It's not an issue of doing what you desire with one function or another;
if you do it at all, inspect.currentframe is appropriate. Rather, the
issue is that a function _shouldn't_ go rooting around in frames up the
stack, except for debugging and other instrumentation purposes: such
"black magic" behavior is not recommended, it damages the important
quality of transparence.

Still, Python does give you plenty enough rope to shoot yourself in the
foot, as befits the principles in the "Spirit of C" which Python also
follows: trust the programmer, don't stop the programmer from doing
something that _needs_ to be done. Just make sure about that 'needs'!-)
Alex
Jul 18 '05 #2

P: n/a
Thanks Alex

I will try this. The need for this is that I have a sort of blackboard
architecture where multiple threads can modify information and I need to
know who is changing what and when.

g
Andre
Alex Martelli wrote:
Andre Meyer <me***@acm.org> wrote:

Hi Pythoneers

In an application I am developing I want to register the invoker of a
method call. Is there any way to find out who is invoking an object's
method? I do not want to rely on the caller telling the callee his name
explicitly.

inspect.currentframe lets you inspect the call frames up the stack,
including (of course) the caller's one; same as sys._getframe. However,
I suggest you reconsider using this in production code, as opposed to
debugging or other development-framework tasks. As the docstring says:

'''
This function should be used for internal and specialized purposes only.
'''

It's not an issue of doing what you desire with one function or another;
if you do it at all, inspect.currentframe is appropriate. Rather, the
issue is that a function _shouldn't_ go rooting around in frames up the
stack, except for debugging and other instrumentation purposes: such
"black magic" behavior is not recommended, it damages the important
quality of transparence.

Still, Python does give you plenty enough rope to shoot yourself in the
foot, as befits the principles in the "Spirit of C" which Python also
follows: trust the programmer, don't stop the programmer from doing
something that _needs_ to be done. Just make sure about that 'needs'!-)
Alex

Jul 18 '05 #3

P: n/a
Andre Meyer <me***@acm.org> wrote:
Thanks Alex
You're welcome.

I will try this. The need for this is that I have a sort of blackboard
architecture where multiple threads can modify information and I need to
know who is changing what and when.


You can record the current thread without black magic, rather than
method/function names. But maybe I don't understand your architecture
well enough to offer suggestions.
Alex
Jul 18 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.