Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Official reason for omitting inspect.currentcallable() ?

Reply
Thread Tools

Official reason for omitting inspect.currentcallable() ?

 
 
kj
Guest
Posts: n/a
 
      08-12-2012


Is there an *explicitly stated* reason (e.g. in a PEP, or in some
python dev list message) for why the inspect module (at least for
Python 2.7) does not include anything like a "currentcallable()"
function that would *stably*[1] return the currently executing
callable object?

(It seems unlikely that the absence in the inspect module of anything
even remotely like such a currentcallable is merely an oversight,
considering how many introspection facilities the inspect module
provides. It seems far more likely that this absence is either
due to some fundamental limitation of Python that makes it impossible
to fully specify such a function, or it is the result of a deliberate
policy against including such a function in inspect.)

Thanks!

[1] By "stably" above I mean, e.g., that the value returned by the
top-level function (object) defined by

def spam():
return inspect.currentcallable()

is *invariant*, in contrast to the value returned by the top-level
function (object) defined by

def ham():
return ham

which is whatever the current value of the 'ham' global happens to
be.

 
Reply With Quote
 
 
 
 
Terry Reedy
Guest
Posts: n/a
 
      08-13-2012
On 8/12/2012 7:06 PM, kj wrote:
>
>
> Is there an *explicitly stated* reason (e.g. in a PEP, or in some
> python dev list message) for why the inspect module (at least for
> Python 2.7)


2.7 is over two years old. Things have been added to the inspect module
since. So when asking about 'why feature x is not present', you should
be asking about 3.3. Enhancement requests should be directed to 3.4.

> does not include anything like a "currentcallable()"


3.x include currentframe() (see below), though it is not guaranteed for
anything other than CPython. 2.x and 3.x have more general functions to
get the entire call stack. Details are certainly implementation specific.

> function that would *stably*[1] return the currently executing
> callable object?


The concepts 'callable' and 'executable' are not the same. Callables
have a .__call__ method that initiates the execution of an executable.
Python-coded functions have a __call__ method that knows how to initiate
the execution of the attached (byte)code object that was compiled from
the Python code. C-coded function wrappers have a __call__ method that
knows how to initiate the execution of object code compiled from C
functions. Other implementations have other __call__ methods. Once the
executable is executing, there is no need for the function and its call
method.

So getting the current callable has to be indirect frame to code object
to name to function object looked up in the parent calling frame. A
direct link would create an unnecessary circular reference.

> [1] By "stably" above I mean, e.g., that the value returned by the
> top-level function (object) defined by
>
> def spam():
> return inspect.currentcallable()
>
> is *invariant*, in contrast to the value returned by the top-level
> function (object) defined by


There have been various proposals and a rejected PEP for accessing 'this
function' from within a function. I do not know if that particular
spelling has been proposed or not.


> def ham():
> return ham
>
> which is whatever the current value of the 'ham' global happens to
> be.

if the def statement is in global scope.

There is no difference unless someone rebind the name, which is normally
done intentionally, for a purpose. Names do not just randomly mutate.

The advantage of access by name is that if someone, whether the original
author or not, wraps the function (say to log calls), then the function
continues to work with the wrapped version.

--
Terry Jan Reedy

 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      08-13-2012
On Sun, 12 Aug 2012 23:06:19 +0000, kj wrote:

> Is there an *explicitly stated* reason (e.g. in a PEP, or in some python
> dev list message) for why the inspect module (at least for Python 2.7)
> does not include anything like a "currentcallable()" function that would
> *stably*[1] return the currently executing callable object?


I doubt it. Should there be? "currentcallable" is not a standard function
in any language I'm familiar with, although I may be missing something
obvious.


--
Steven
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      08-13-2012
On Mon, Aug 13, 2012 at 6:24 PM, Steven D'Aprano
<(E-Mail Removed)> wrote:
> On Sun, 12 Aug 2012 23:06:19 +0000, kj wrote:
>
>> Is there an *explicitly stated* reason (e.g. in a PEP, or in some python
>> dev list message) for why the inspect module (at least for Python 2.7)
>> does not include anything like a "currentcallable()" function that would
>> *stably*[1] return the currently executing callable object?

>
> I doubt it. Should there be? "currentcallable" is not a standard function
> in any language I'm familiar with, although I may be missing something
> obvious.


I'm not familiar with it by that name, but Pike's this_function is
what the OP's describing.

(Yes, I'm citing Pike again. Sorry.)

It's a useful construct in theory when you want to write in recursion,
which was part of the rationale behind PEP 3130 (btw, Terry, it would
have been nice if you'd mentioned the number instead of sending me to
the index to try to figure out which one you were referring to, but
anyway). But how often is it actually useful in practice? I've never
actually used this_function other than in writing a crazy recursive
lambda (was testing different languages' handling of infinite
recursion - high level languages shouldn't segfault, one much-maligned
language DOES).

ChrisA
 
Reply With Quote
 
kj
Guest
Posts: n/a
 
      08-13-2012
In <(E-Mail Removed)> Chris Angelico <(E-Mail Removed)> writes:

>I'm not familiar with it by that name, but Pike's this_function is
>what the OP's describing.


You got it.

>It's a useful construct in theory when you want to write in recursion,
>which was part of the rationale behind PEP 3130


Thank you!

kj
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
asp.net page won't work with dll, what am I omitting? BLACKDOG157@LYCOS.COM ASP .Net 1 12-20-2005 03:13 PM
Omitting the .ASPX Extension RC ASP .Net 5 11-29-2004 07:18 AM
log4j - Omitting stack trace with ConsoleAppender Christian Ashby Java 5 08-24-2004 10:07 PM
Since Pentax is the Official Digital of the Internet, Who is the Official Digital of this NG? Ed Smith Digital Photography 2 04-16-2004 09:25 PM
omitting config values Eric Tishkoff ASP .Net 2 07-02-2003 05:18 AM



Advertisments