(original) (raw)

On 21 Jan 2014 08:20, "Serhiy Storchaka" <storchaka@gmail.com> wrote:
\>
\> 20.01.14 20:09, Georg Brandl написав(ла):
\>
\>> Am 20.01.2014 14:31, schrieb Serhiy Storchaka:
\>>>
\>>> 20.01.14 15:03, Nick Coghlan написав(ла):
\>>>>
\>>>> On 20 January 2014 21:14, Serhiy Storchaka <storchaka@gmail.com> wrote:
\>>>>>
\>>>>> 20.01.14 10:05, Larry Hastings написав(ла):
\>>>>>>
\>>>>>> Contestant 4: "Put in clinic directory, add .h"
\>>>>>>
\>>>>>> foo.c -> clinic/foo.c.h
\>>>>>> foo.h -> clinic/foo.h.h
\>>>>>
\>>>>>
\>>>>>
\>>>>> -1\. (Generated files are located far from origins, directory name clutters
\>>>>> the namespace of directory names).
\>>>>
\>>>>
\>>>> Larry's not talking about a top level directory here (at least I hope
\>>>> he isn't). This proposal would mean using "Objects/clinic",
\>>>> "Python/clinic", "Modules/clinic" as appropriate.
\>>>
\>>>
\>>> This means the appearance of directories with the common name "clinic"
\>>> in random places of the source tree. Some special name ("\_\_clinic\_\_",
\>>> ".clinic") looks slightly less confusing to me.
\>>
\>>
\>> "clinic" shouldn't be such a common name in C soures :)
\>
\>
\> Sources tree already has one "clinic" directory (Tools/clinic/).

This observation and the cjkcodecs comparison has prompted me to switch my votes for #4 and #5: +1 for \_\_clinic\_\_, +0 for clinic.

I still prefer a subdirectory to adjacent files, though.

Cheers,
Nick.

>
\>
\>
\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\> Python-Dev mailing list
\> Python-Dev@python.org
\> https://mail.python.org/mailman/listinfo/python-dev
\> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com