[Python-Dev] Changing Clinic's output

Nick Coghlan ncoghlan at gmail.com
Tue Jan 7 23:52:09 CET 2014

On 8 Jan 2014 06:24, "Brett Cannon" <brett at python.org> wrote:
> On Tue, Jan 7, 2014 at 4:44 PM, Stefan Krah <stefan at bytereef.org> wrote:
>> Antoine Pitrou <solipsis at pitrou.net> wrote:
>> > Several solutions have been proposed:
>> > - move all generated code to separate C files, which would then be
>> >   #included'd into the main module file
>> +1 for the reasons that Serhiy has listed.  Additionally, if custom
>> are implemented, the generated code will take up even more space (look
>> at Cython's custom parsers).
> Guido has already said he hates constructing files that way so that
simply isn't going to happen.
> I personally don't care about this whole discussion (and I suspect people
being quiet don't either). At this point the amount of arguing on this
topic could have been used more constructively converting code and then, if
necessary, tweaking the output of Argument Clinic later.

I haven't had a chance to look at any of the newly converted code (due to
vacation and linux.conf.au), so I'm happy to take the word of the folks
doing the conversion that the current behaviour is inconvenient.

I think the split VCS history where changing clinic's output without
changing the function declarations *doesn't* show up as altering the
manually maintained source files (but only clinic and separate generated
"XYZ_clinic.c" files) is a compelling practical argument in favour of the
split file approach, even if it makes execution jump around a little

Failing that, I like Larry's proposal to switch to generating only
prototypes inline and having the wrapper implementations at a common point
in each file, reducing the visible boilerplate when looking at individual


> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140108/f3a04334/attachment.html>

More information about the Python-Dev mailing list