Larry Hastings, 03.12.2012 23:29:
Say there, the Python core development community! Have I got a question for you!
*ahem*
Which of the following four options do you dislike least? ;-)
1) CPython continues to provide no "function signature" objects (PEP 362) or inspect.getfullargspec() information for any function implemented in C.
I would love to see Cython generated functions look and behave completely like normal Python functions at some point, so this is the option I dislike most.
2) We add new hand-coded data structures representing the metadata necessary for function signatures for builtins. Which means that, when defining arguments to functions in C, we'd need to repeat ourselves *even more* than we already do.
3) Builtin function arguments are defined using some seriously uncomfortable and impenetrable C preprocessor macros, which produce all the various types of output we need (argument processing code, function signature metadata, possibly the docstrings too).
4) Builtin function arguments are defined in a small DSL; these are expanded to code and data using a custom compile-time preprocessor step. [...] * There's actually a fifth option, proposed by Brett Cannon. We constrain the format of docstrings for builtin functions to make them machine-readable, then generate the function signature objects from that. But consider: generating *everything* in the signature object may get a bit tricky (e.g. Parameter.POSITIONAL_ONLY), and this might gunk up the docstring.
Why not provide a constructor for signature objects that parses the signature from a string? For a signature like def func(int arg1, float arg2, ExtType arg3, *, object arg4=None) -> ExtType2: ... you'd just pass in this string: (arg1 : int, arg2 : float, arg3 : ExtType, *, arg4=None) -> ExtType2 or maybe prefixed by the function name, don't care. Might make it easier to pass it into the normal parser. For more than one alternative input type, use a tuple of types. For builtin types that are shadowed by C type names, pass "builtins.int" etc. Stefan