On Mon, Dec 3, 2012 at 5:29 PM, Larry Hastings <la...@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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
