Official reason for omitting inspect.currentcallable() ?

Discussion in 'Python' started by kj, Aug 13, 2012.

  1. kj

    kj Guest

    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.
    kj, Aug 13, 2012
    #1
    1. Advertising

  2. kj

    Terry Reedy Guest

    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
    Terry Reedy, Aug 13, 2012
    #2
    1. Advertising

  3. 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
    Steven D'Aprano, Aug 13, 2012
    #3
  4. On Mon, Aug 13, 2012 at 6:24 PM, Steven D'Aprano
    <> 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
    Chris Angelico, Aug 13, 2012
    #4
  5. kj

    kj Guest

    In <> Chris Angelico <> 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
    kj, Aug 13, 2012
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Eric Tishkoff

    omitting config values

    Eric Tishkoff, Jul 1, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    326
    Natty Gur
    Jul 2, 2003
  2. RC

    Omitting the .ASPX Extension

    RC, Nov 28, 2004, in forum: ASP .Net
    Replies:
    5
    Views:
    370
    Klaus H. Probst
    Nov 29, 2004
  3. Replies:
    1
    Views:
    373
    Karl Seguin
    Dec 20, 2005
  4. Christian Ashby
    Replies:
    5
    Views:
    7,799
    Oscar kind
    Aug 24, 2004
  5. deluxstar
    Replies:
    5
    Views:
    857
    Terry Reedy
    Sep 25, 2010
Loading...

Share This Page