homepage

Not sure if this has been brought before but how about extending getargspec to work with callable instances, i.e. make it equivalent to getargspec(obj.__call__) ?

I second this, I depend on this monkeypatch for my turbogears projects, where I use callable objects as error handlers:
 def getargspec(func):
 if getattr(func, '__call__') and not isfunction(func) and not ismethod(func):
 func = func.__call__
 if ismethod(func):
 func = func.im_func
 if not isfunction(func):
 raise TypeError('arg is not a Python function')
 args, varargs, varkw = getargs(func.func_code)
 return args, varargs, varkw, func.func_defaults
but I suppose 2.7 is locked to this change so I propose it for 3.x

Adding to nosy the developers who last touched inspect.

Doesn't seem like an unreasonable request. Nick / Benjamin, what do you think?

This API has changed around a bit in 3.x, so it is actually inspect.getfullargspec that needs to change (getargspec will inherit the new behaviour though, since it uses getfullargspec internally)
With appropriate docs and tests updates, I don't see a problem with adding the feature, though. Docs should note and tests should ensure that this only goes one level deep - if __call__ isn't a real function either, inspect shouldn't try to follow the descriptor chain down the rabbit hole. Anything else runs the risk of infinite recursion in the face of things like "inspect.getargspec(list)".

I can produce a patch w/ tests and documentation for you to review Nick.

I've ran into the same problem with getfullargspec not supporting callables, so I've written patch with docs and tests, that adds support for any Python callable. As a result of getfullargspec's implementation change, getargspec function also supports callables.

I'm -0.5. I think the current patch makes too many assumptions for the caller. For example, someone calling a class may really desire __new__'s signature, not that of __init__. Moreover, conceptually, getargspec() returns the argspec of a directly callable *function* or *method*.

Right. For a callable object (instance with __call__ method), it's unambiguous which signature you want. For a class it's ambiguous.

Agree, support for __new__ or __init__ methods would add some ambiquity, so i've decided to drop __init__ support from patch. Patch has been reuploaded.

Would someone please review the patch file as it's out of my league.

This is now fixed in #17481.