"inspect.getargspec()" and "inspect.getcallargs()" don't work for builtins #60694

Activity

1. jcea commented on Nov 17, 2012

   

   jcea

   on Nov 17, 2012

   MemberAuthor

   More actions

   Yesterday I was attending a conference about a MOCK like library and the speaker told us about some "inspect" functionalities not working correctly with builtins. For instance:

   """
   Python 3.3.0 (default, Oct  2 2012, 02:07:16) 
   [GCC 4.4.3] on linux
   Type "help", "copyright", "credits" or "license" for more information.
   >>> import inspect
   >>> def f(a=None) :
   ...   pass
   ... 
   >>> inspect.getcallargs(f)
   {'a': None}
   >>> inspect.getargspec(f)
   ArgSpec(args=['a'], varargs=None, keywords=None, defaults=(None,))
   >>> inspect.getcallargs(list)
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
     File "/usr/local/lib/python3.3/inspect.py", line 993, in getcallargs
       spec = getfullargspec(func)
     File "/usr/local/lib/python3.3/inspect.py", line 850, in getfullargspec
       raise TypeError('{!r} is not a Python function'.format(func))
   TypeError: <class 'list'> is not a Python function
   >>> inspect.getargspec(list)
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
     File "/usr/local/lib/python3.3/inspect.py", line 823, in getargspec
       getfullargspec(func)
     File "/usr/local/lib/python3.3/inspect.py", line 850, in getfullargspec
       raise TypeError('{!r} is not a Python function'.format(func))
   TypeError: <class 'list'> is not a Python function
   >>> 
   """

   Can we annotate builtins to support this?. What about types defined in CModules?
2. jcea

   changed the title [-]"inspect.getargspec()" and "inspect.getcallargs()" don't work with builtins[/-] [+]"inspect.getargspec()" and "inspect.getcallargs()" don't work for builtins[/+] on Nov 17, 2012
3. jcea

   added

   type-featureA feature request or enhancementA feature request or enhancement

   on Nov 17, 2012
4. jcea commented on Nov 17, 2012

   

   jcea

   on Nov 17, 2012

   MemberAuthor

   More actions

   I am fully aware that the interpreter doesn't know how a method/function written in C is going to parse the parameter list/keywords. And that even if we solve this (for instance, with annotations that create wrappers calling "PyArg_Parse()" automatically), every C extension out there would need to support it too.

   Just brainstorming.
5. brettcannon commented on Nov 17, 2012

   

   brettcannon

   on Nov 17, 2012

   Member

   More actions

   So at this point you should use inspect.signature(), not getfullargspec().

   With that you could do this if you either allowed setting the __signature__ attribute and then provided code that would set it, made __signature__ a property that returned the Signature object if desired on a built-in, or come up with some automated way to take the argument string from PyArg_Parse() as you suggested.
6. larryhastings commented on Nov 17, 2012

   

   larryhastings

   on Nov 17, 2012

   Contributor

   More actions

   I'm working on a solution for this--expect an announcement on c.l.p-d in, oh, a week.
7. larryhastings

   self-assigned this

   on Nov 17, 2012
8. jcea commented on Nov 30, 2012

   

   jcea

   on Nov 30, 2012

   MemberAuthor

   More actions

   Larry, Ping... :-)
9. larryhastings commented on Dec 3, 2012

   

   larryhastings

   on Dec 3, 2012

   Contributor

   More actions

   http://mail.python.org/pipermail/python-dev/2012-December/122920.html
10. davidvilla commented on Dec 4, 2012

    

    davidvillamannequin

    on Dec 4, 2012

    Mannequin

    More actions

    What about something like gobject.introspection?
    https://live.gnome.org/GObjectIntrospection/
11. jcea commented on Dec 6, 2012

    

    jcea

    on Dec 6, 2012

    MemberAuthor

    More actions

    David, please subscribe to Issue bpo-16612.
12. berkerpeksag commented on Dec 9, 2012

    

    berkerpeksag

    on Dec 9, 2012

    Member

    More actions

    This looks like a duplicate of bpo-1748064.
13. 1st1 commented on Jan 11, 2014

    

    1st1

    on Jan 11, 2014

    Member

    More actions

    This is related to issue bpo-17481
14. 1st1 commented on Jan 27, 2014

    

    1st1

    on Jan 27, 2014

    Member

    More actions

    Closing this issue. See bpo-17481 for details.
15. 1st1

    closed this as completedon Jan 27, 2014
16. ezio-melotti

    transferred this issue fromon Apr 10, 2022