This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: inspect.getargspec fails on built-in or slot wrapper methods
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.2
process
Status: closed Resolution: duplicate
Dependencies: Superseder: "inspect.getargspec()" and "inspect.getcallargs()" don't work for builtins
View: 16490
Assigned To: Nosy List: BreamoreBoy, Trundle, asvetlov, daniel.urban, georg.brandl, hawkerm, jcea, michael.foord, ncoghlan
Priority: normal Keywords:

Created on 2007-07-04 21:22 by hawkerm, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
inspecttrace.txt hawkerm, 2007-07-04 21:22 Interpreter Trace of inspect lib
Messages (7)
msg32451 - (view) Author: Michael A. Hawker (hawkerm) Date: 2007-07-04 21:22
Hi, I'm new here, but I'm running into a little trouble with complex introspection techniques.

I'm using Windows XP SP2 on an AMD64 chip.

Tying to do some introspection on base types provides little information about the function as getargspec will not accept the slot wrapper or a built-in function as an argument (see attached interpreter trace).

i.e. when trying to analyze functions such as list.remove, list.__getitem__, len, etc...

This seems like abnormal behavior as it seems contrary as these are methods and functions, and the help function (while only providing the doc string) still provides information about the function, only in a different harder to parse format.

Do I need to make a stronger argument?  It would be very useful for the work I'm doing.

Attached is a trace of various scenarios involving this issue and how it seems contrary to the expected behavior.
msg109840 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-07-10 10:15
I think this should be treated as a bug.
msg112491 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-08-02 16:19
It *is* a feature request.  The signature of functions implemented in C is currently not exposed to introspection.
msg136080 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2011-05-16 11:54
If PEP 362 is implemented it would either fix or obsolete this issue:

http://www.python.org/dev/peps/pep-0362/
msg136081 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2011-05-16 11:56
Sorry, *could* fix / obsolete this issue. i.e. builtin functions / methods could support pep 362 - the reference implementation is in pure python and doesn't work for C functions.
msg136083 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2011-05-16 12:05
The challenge with C functions is that this becomes *additional* metadata that somehow needs to be provided to the method and function creation process. None of our APIs are set up to accept that information (and obviously no code is set up to provide it, either).

What might be nice is a way to graft the signature information from a Python implementation onto a C implementation (which would be quite straightforward given PEP 362 and a writable __signature__ slot in the C objects).

The other virtue of this approach is that the Python metadata will be testable, so it doesn't run the same risk of getting out of date that manually maintained metadata at the C level does. It would work naturally for C acceleration modules, and wouldn't be any more effort to add for pure C code than direct annotations at the C level would be.
msg177334 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-12-11 11:11
Close the issue as duplicate for #16490
History
Date User Action Args
2022-04-11 14:56:25adminsetgithub: 45151
2012-12-11 11:11:46asvetlovsetstatus: open -> closed

superseder: "inspect.getargspec()" and "inspect.getcallargs()" don't work for builtins

nosy: + asvetlov
messages: + msg177334
resolution: duplicate
stage: test needed -> resolved
2012-12-10 12:23:01jceasetnosy: + jcea
2011-05-16 16:35:58daniel.urbansetnosy: + daniel.urban
2011-05-16 12:05:41ncoghlansetnosy: + ncoghlan
messages: + msg136083
2011-05-16 11:56:20michael.foordsetmessages: + msg136081
2011-05-16 11:54:31michael.foordsetmessages: + msg136080
2011-05-16 11:51:53michael.foordsetnosy: + michael.foord
2010-08-09 04:23:36terry.reedysetversions: - Python 3.1, Python 2.7
2010-08-03 09:08:47Trundlesetnosy: + Trundle
2010-08-02 16:19:58georg.brandlsettype: behavior -> enhancement

messages: + msg112491
nosy: + georg.brandl
2010-07-10 10:15:11BreamoreBoysetversions: + Python 3.2
nosy: + BreamoreBoy

messages: + msg109840

type: enhancement -> behavior
2009-04-06 10:31:34ajaksu2setstage: test needed
type: enhancement
versions: + Python 3.1, Python 2.7, - Python 2.5
2007-07-04 21:22:07hawkermcreate