On Mon, Dec 3, 2012 at 5:29 PM, Larry Hastings <larry@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.