[Python-Dev] Changing Clinic's output (original) (raw)

Brett Cannon brett at python.org
Wed Jan 8 17:04:01 CET 2014

On Wed, Jan 8, 2014 at 10:46 AM, Larry Hastings <larry at hastings.org> wrote:

On 01/08/2014 07:33 AM, Brett Cannon wrote: So let's make this idea concrete to focus a possible discussion. Using the example from the Clinic HOWTO and converting to how I see it working: [...] Yep. And what I was proposing is much the same, except there are a couple extra lines in the "generated code" section. I'd keep the #define for the methoddef there, and add a prototype for the generated parsing function (picklePicklerdump) and the docstring.

I assume that's for flexibility in case someone has their module structured in a way that doesn't lend itself to having it all accumulated at the end of the file? Or is there something I'm overlooking? I would assume being able to put the accumulator block where ever you want with enough forward declarations would still be enough to allow for it to work with almost any structured format of a file and have almost all the generated code in a single place. I can definitely live with what you are proposing, just trying to understand the logic as shifting almost all generated stuff in a single place does make Clinic comments read like fancy docstrings which is nice.

#################### /*[clinic input] pickle.Pickler.dump obj: 'O' The object to be pickled. / Write a pickled representation of obj to the open file. [clinic start generated code]*/ PyDocVAR(picklePicklerdump_doc);_ static PyObject * picklePicklerdump(PyObject *args); #define PICKLEPICKLERDUMPMETHODDEF _ {"dump", (PyCFunction)picklePicklerdump, METHO, picklePicklerdump_doc}, static PyObject * picklePicklerdumpimpl(PyObject *self, PyObject *obj) /*[clinic end generated code: checksum=3bd30745bf206a48f8b576a1da3d90f55a0a4187]*/ { /* Check whether the Pickler was initialized correctly (issue3664). Developers often forget to call init() in their subclasses, which would trigger a segfault without this check. */ ... } Another potential perk of doing a gathering of Clinic output is that if we take it to it's logical conclusion, then you can start to do things like define a method like pickle.Pickler.init, etc., have Clinic handle docstrings for modules and classes, and then it can end up spitting out the type struct entirely for you, negating the typical need to do all of that by hand (I don't know about the rest of you but I always just copy and paste that struct anyway, so having a tool slot in the right method names for the right positions would save me busy work). Surely new code should use the functional API for creating types?

Yes. Shows how long it has been since I have written a C type from scratch. =)

Anyway, yes, in the future it would be nice to get rid of a bunch of the busywork associated with implementing a Python builtin type, and Argument Clinic could definitely help with that.

I think that will be the big long-term win; taking out nearly all boilerplate in creating an extension module and maintaining it (in case something changes, e.g. the module init function signature). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140108/cded8edd/attachment.html>

More information about the Python-Dev mailing list