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.
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.
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.
