[Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython

[Stefan Behnel]

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