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

[Brett Cannon]

On Mon, Dec 3, 2012 at 5:29 PM, Larry Hastings <larry at hastings.org> wrote:

>
> 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.
>
> 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.
>
>
> All the core devs I've asked said "given all that, I'd prefer the
> hairy preprocessor macros".  But by the end of the conversation
> they'd changed their minds to prefer the custom DSL.  Maybe I'll
> make a believer out of you too--read on!
>
>
[snip]


> * 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.
>

I should mention that I was one of the people Larry pitched this to and
this fifth option was before I fully understood the extent the DSL
supported the various crazy options needed to support all current use-cases
in CPython.

Regardless I fully support what Larry is proposing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121204/e9d0ea0d/attachment.html>