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

Serhiy Storchaka storchaka at gmail.com
Sat Jan 18 10:02:20 CET 2014

After the latest Argument Clinic updates my patches began to look much better. 
Thank you Larry. Now Argument Clinic supports output to side file (this is not 
default, you should specify "output preset file" at the start of first clinic 

I already wrote about this here, but it seems my post got lost in the heart of 
one of the numerous threads and was not noticed. So I repeat it as a separate 

Now generated files have suffixes .clinic.c. I think it will be better, if they 
will end at special suffix (.c.clinic or even just .clinic).

My reasons: 

1. I very very often use global search in sources. It's my way of navigation 
and it's my way of investigations. I don't want to get false results in 
generated files. And it is much easy to specify mask '*.[ch]' or '*.c,*.h' 
(depending on tool) than specify a mask and negative mask. The latter is even 
not always possible, I can write cumbersome expression for the find command, 
but Midnight Commander doesn't support negative masks at all (and perhaps your 
favorite IDE doesn't support them too). 

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. 

3. Pathname expansion works better with unique endings, You can open all 
Modules/_io/*.c files, but unlikely you so interested in *.clinic.c files which 
are matched by former pattern. 

4. .c suffix at the end lies. This is not compilable C source file. This file 
should be included in other C source file. This will confuse accidental user 
and other tools. Including Argument Clinic itself, this is why it inserts the 
"preserve" directive at the start of generated file. But other tools have no 
such sign.

My attempt to convince Larry on IRC failed. He agreed to change his opinion 
only if other core developers persuade him. I ask you to help me convince 

More information about the Python-Dev mailing list