[Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
brett at python.org
Tue Dec 4 20:21:39 CET 2012
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!
> 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!
> * 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
Regardless I fully support what Larry is proposing.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev