[Python-Dev] .clinic.c vs .c.clinic (original) (raw)

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