Home Original page

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

Ethan Furman ethan at stoneleaf.us
Sun Jan 19 17:29:25 CET 2014 
On 01/19/2014 03:32 AM, Georg Brandl wrote:
> Am 19.01.2014 11:19, schrieb Larry Hastings:
>> On 01/18/2014 10:36 PM, Nick Coghlan wrote:
>>> On 19 January 2014 10:44, Steve Dower <Steve.Dower at microsoft.com> wrote:
>>>> Visual Studio will try to compile them if they end with .c, though this can
>>>> be disabled on a per-file basis in the project file. Files ending in .h
>>>> won't be compiled, though changes should be detected and cause the .c files
>>>> that include them to be recompiled.
>>> That sounds like a rather good argument for .clinic.h over .clinic.c :)
>>>
>>> My assessment of the thread is that .clinic.h will give us the best
>>> overall tool compatibility.
>>
>> Yeah, I'm tipping pretty far towards "foo.c" -> "foo.clinic.h".
>>
>> But there's one onion in the ointment: what should "foo.h" generate?  The day
>> may yet arrive when we have Argument Clinic code in foo.{ch}.
>>
>> Not kidding, my best idea so far is "foo.clinic.h.h",
>
> Why not always put clinic into its own directory?
>
> Modules/mathmodule.c -> Modules/clinic/mathmodule.c.h
> Modules/mathmodule.h -> Modules/clinic/mathmodule.h.h
>
> At least that is consistent, allows easy exclusion in tools, and gets rid
> of the additional "clinic" in the filename.

+1

If AC will work with both .c and .h files. I think a separate directory is the way to go.

--
~Ethan~
More information about the Python-Dev mailing list