[issue17481] inspect.getfullargspec should use __signature__

Nick Coghlan report at bugs.python.org
Sun Jan 19 05:36:06 CET 2014


Nick Coghlan added the comment:

getargspec() is just a thin wrapper around getfullargspec(), so we get that for free.

Similarly, getcallargs() is also implicitly updated to full PEP 362 support by changing the implementation of getfullargspec().

The other two standard library consumers appear to be IDLE (as Terry noted above) and xmlrpc.server.ServerHTMLDoc.docroutine (the self-documenting XML-RPC server API, which sadly appears to be lacking test cases).

Reviewing those cases (especially the XML-RPC one) have convinced me we need a backwards compatibility fallback in the updated getfullargspec implementation. Specifically, if the new API throws ValueError (because it can't find a way to build a coherent signature object), we should fall back to the old approach. Otherwise we run the risk of introducing unexpected exceptions into introspection code.

That is, the new call to signature in getfullargspec should look something like:

    try:
        sig = signature(func)
    except ValueError:
        if not hasattr(func, "__code__"):
            raise # The legacy fallback doesn't support this input type
        # The callable signature appears to be incoherent, so we fall
        # back to the legacy implementation to preserve compatibility
        args, varargs, kwonlyargs, varkw = _getfullargs(func.__code__)
        return FullArgSpec(args, varargs, varkw, func.__defaults__,
                kwonlyargs, func.__kwdefaults__, func.__annotations__)

I suspect this may actually be a better solution for IDLE rather than updating it to call inspect.signature directly (since IDLE probably *wants* the more graceful fallback to the old behaviour). 

The way I would document all this in What's New is to update the current argument clinic section to also explain that we've taken advantage of PEP 362 to improve introspection in multiple areas, including for code that is using the introspection APIs that predate PEP 362.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17481>
_______________________________________


More information about the Python-bugs-list mailing list