<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 14, 2014 at 3:12 PM, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span> wrote:</div>
<div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Tue, 14 Jan 2014 12:22:12 -0800<br>
Larry Hastings <<a href="mailto:larry@hastings.org">larry@hastings.org</a>> wrote:<br>
><br>
> <a href="https://bitbucket.org/larry/clinic-buffer-samples/src" target="_blank">https://bitbucket.org/larry/clinic-buffer-samples/src</a><br>
><br>
> In it I converted Modules/_pickle.c four different ways. There's a<br>
> README, please read it.<br>
<br>
</div>I'm +1 on the sidefile approach. +0 on the various buffer approaches.<br>
-0.5 on the current "sprinkled everywhere" approach.<br></blockquote></div><div class="gmail_extra"><br></div>After converting a few modules, I feel about the same. The sprinkling does clutter</div><div class="gmail_extra">
the file. Although, I do wonder if we can simplify things a bit for the "sideline" file</div><div class="gmail_extra">by using macros and headers. You could write the original definition like:</div><div class="gmail_extra">
<br></div><div class="gmail_extra"><div class="gmail_extra"> /*[clinic input begin]</div><div class="gmail_extra"> _pickle.PicklerMemoProxy.copy</div><div class="gmail_extra"> </div><div class="gmail_extra"> self: PicklerMemoProxyObject</div>
<div class="gmail_extra"> </div><div class="gmail_extra"> Copy the memo to a new object.</div><div class="gmail_extra"> [clinic input end]*/</div><div class="gmail_extra"> static PyObject *</div><div class="gmail_extra">
_PICKLE_PICKLERMEMOPROXY_COPY(PyObject *self, PyObject *Py_UNUSED(ignored))</div><div class="gmail_extra"> {</div><div class="gmail_extra"> ...</div><div class="gmail_extra"> }</div><div><br></div><div>and then generate a header like:</div>
<div><br></div><div><div> PyDoc_STRVAR(_pickle_PicklerMemoProxy_copy__doc__,</div><div> "copy()\n"</div><div> "Copy the memo to a new object.");</div><div><br></div><div> #define _PICKLE_PICKLERMEMOPROXY_COPY_METHODDEF \</div>
<div> {"copy", (PyCFunction)_pickle_PicklerMemoProxy_copy, METH_NOARGS, _pickle_PicklerMemoProxy_copy__doc__},</div><div><br></div><div> static PyObject *</div><div> _pickle_PicklerMemoProxy_copy_impl(PicklerMemoProxyObject *self);</div>
<div><br></div><div> #define _PICKLE_PICKLERMEMOPROXY_COPY(a, b) \</div><div> _pickle_PicklerMemoProxy_copy(PyObject *self, PyObject *Py_UNUSED(ignored)) \</div><div> { \</div><div> PyObject *return_value = NULL; \</div>
<div> \</div><div> return_value = _pickle_PicklerMemoProxy_copy_impl((PicklerMemoProxyObject *)self); \</div><div> \</div><div> return return_value; \</div>
<div> } \</div><div> \</div><div> static PyObject * \</div><div> _pickle_PicklerMemoProxy_copy_impl(PicklerMemoProxyObject *self) \</div></div><div><br></div><div>This way the docstring, method def, and argument parsing code is out of the way, but</div>
<div>you still retain the helpful comments in the implementation file. I am pretty sure this</div><div>gets around the "where do I inject the side file part" too. You also don't have to do</div><div>much more editing than the original scheme: write the clinic comment, #iinclude a</div>
<div>header, and then apply the macro.</div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div>That being said, this is somewhat half baked and some folks don't like macros. I just</div><div>wanted to throw it out there since it seems like a reasonable compromise.</div>
<div><br></div><div>FWIW, I have worked on several large programs that generate C header and implementation</div><div>files on the side and it has never bothered me that much. Well, unless, something goes<br></div><div>wrong :-)</div>
<div><br></div>-- <br># Meador
</div></div>