[Python-Dev] .clinic.c vs .c.clinic

[Nick Coghlan]

On 18 Jan 2014 19:08, "Chris Angelico" <rosuav at gmail.com> wrote:
>
> On Sat, Jan 18, 2014 at 8:02 PM, Serhiy Storchaka <storchaka at gmail.com>
wrote:
> > 2. I'm not use any IDE, but if you use, it can be important for you. If
IDE
> > shows sources tree, unlikely you want to see generated *.clinic.c files
in
> > them. This will increase the list of sources almost twice.
>
> A point for the contrary side: In any editor or IDE with syntax
> highlighting, a .clinic.c file will be highlighted as C code, but it
> would take extra configuration to handle a .clinic file that way. But
> that's a relatively minor consideration (AIUI most people won't be
> looking at the .clinic files much, and for those who do, configure the
> editor appropriately).

I can argue either side, but the biggest potential problem I see with
Serhiy's suggestion is the likelihood of breaking automatic cross
referencing of symbols in most IDEs, as well as causing possible issues for
interactive debuggers. These are at least valid fragments of C files, even
if they're not designed to be compiled independently. However, if both
Visual Studio and gdb can still find the symbols correctly, even with the
".clinic" extension, then I would consider that a point strongly in favour
of Serhiy's suggestion.

Picking up on a side comment in Serhiy's post, based on my experience
reviewing a patch that included changes to clinic input blocks, I'd also
prefer if a parallel file was the default, and single file was opt in (or
not allowed at all). Getting changes reviewed and merged is one of the
biggest bottlenecks in our workflow, and the inline version of clinic is
much harder to review due to the intermingled diff of clinic input and
generated output.

Cheers,
Nick.

>
> ChrisA
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140118/3b3bb220/attachment.html>