Official reason for omitting inspect.currentcallable() ?

[Terry Reedy]

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