[Python-Dev] Changing Clinic's output
Meador Inge
meadori at gmail.com
Wed Jan 15 06:23:53 CET 2014
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>
More information about the Python-Dev
mailing list