[Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
stefan_ml at behnel.de
Tue Dec 4 16:36:06 CET 2012
Larry Hastings, 03.12.2012 23:29:
> Say there, the Python core development community! Have I got
> a question for you!
> 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
> 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.
More information about the Python-Dev