Author ncoghlan
Recipients Claudiu.Popa, larry, michael.foord, ncoghlan, terry.reedy, yselivanov
Date 2014-01-19.04:36:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1390106166.02.0.167808185855.issue17481@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2014-01-19 04:36:06ncoghlansetrecipients: + ncoghlan, terry.reedy, larry, michael.foord, Claudiu.Popa, yselivanov
2014-01-19 04:36:06ncoghlansetmessageid: <1390106166.02.0.167808185855.issue17481@psf.upfronthosting.co.za>
2014-01-19 04:36:06ncoghlanlinkissue17481 messages
2014-01-19 04:36:05ncoghlancreate