[Python-Dev] Changing Clinic's output

[Brett Cannon]

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
> (_pickle_Pickler_dump) 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]*/
>  PyDoc_VAR(pickle_Pickler_dump__doc__);
>
> static PyObject *
> _pickle_Pickler_dump(PyObject *args);
>
>  #define _PICKLE_PICKLER_DUMP_METHODDEF    \
> {"dump", (PyCFunction)_pickle_Pickler_dump, METH_O,
> _pickle_Pickler_dump__doc__},
>
>  static PyObject *
> pickle_Pickler_dump_impl(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>