[Python-Dev] Changing Clinic's output

[Meador Inge]

On Tue, Jan 14, 2014 at 3:12 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

On Tue, 14 Jan 2014 12:22:12 -0800
> Larry Hastings <larry at hastings.org> wrote:
> >
> >     https://bitbucket.org/larry/clinic-buffer-samples/src
> >
> > In it I converted Modules/_pickle.c four different ways.  There's a
> > README, please read it.
>
> I'm +1 on the sidefile approach. +0 on the various buffer approaches.
> -0.5 on the current "sprinkled everywhere" approach.
>

After converting a few modules, I feel about the same.  The sprinkling does
clutter
the file.  Although, I do wonder if we can simplify things a bit for the
"sideline" file
by using macros and headers.  You could write the original definition like:

  /*[clinic input begin]
  _pickle.PicklerMemoProxy.copy

    self: PicklerMemoProxyObject

  Copy the memo to a new object.
  [clinic input end]*/
  static PyObject *
  _PICKLE_PICKLERMEMOPROXY_COPY(PyObject *self, PyObject
*Py_UNUSED(ignored))
  {
      ...
  }

and then generate a header like:

  PyDoc_STRVAR(_pickle_PicklerMemoProxy_copy__doc__,
  "copy()\n"
  "Copy the memo to a new object.");

  #define _PICKLE_PICKLERMEMOPROXY_COPY_METHODDEF    \
      {"copy", (PyCFunction)_pickle_PicklerMemoProxy_copy, METH_NOARGS,
_pickle_PicklerMemoProxy_copy__doc__},

  static PyObject *
  _pickle_PicklerMemoProxy_copy_impl(PicklerMemoProxyObject *self);

  #define _PICKLE_PICKLERMEMOPROXY_COPY(a, b) \
  _pickle_PicklerMemoProxy_copy(PyObject *self, PyObject
*Py_UNUSED(ignored)) \
  { \
      PyObject *return_value = NULL; \
                                     \
      return_value =
_pickle_PicklerMemoProxy_copy_impl((PicklerMemoProxyObject *)self); \
                                     \
      return return_value; \
  } \
    \
  static PyObject * \
  _pickle_PicklerMemoProxy_copy_impl(PicklerMemoProxyObject *self) \

This way the docstring, method def, and argument parsing code is out of the
way, but
you still retain the helpful comments in the implementation file.  I am
pretty sure this
gets around the "where do I inject the side file part" too.  You also don't
have to do
much more editing than the original scheme: write the clinic comment,
#iinclude a
header, and then apply the macro.

That being said, this is somewhat half baked and some folks don't like
macros.  I just
wanted to throw it out there since it seems like a reasonable compromise.

FWIW, I have worked on several large programs that generate C header and
implementation
files on the side and it has never bothered me that much.  Well, unless,
something goes
wrong :-)

-- 
# Meador
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140114/13048a80/attachment.html>