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

Larry Hastings larry at hastings.org
Wed Jan 22 22:41:32 CET 2014


On 01/22/2014 08:20 AM, Serhiy Storchaka wrote:
> 20.01.14 13:14, Serhiy Storch

> aka написав(ла):
>>> Contestant 5: "Put in __clinic__ directory, add .h"
>>>
>>>     foo.c -> __clinic__/foo.c.h
>>>     foo.h -> __clinic__/foo.h.h
>>
>> -0.5.
>
> As far as 4 and 5 have equal total votes, I change my vote for 5 from 
> -0.5 to -0.

Too late!  The poll ended Tuesday evening at 11pm, PST (GMT -0800). ;-)

And yes, with 13 votes cast, it ended with a tie between 
"clinic/{filename}.h" and  "__clinic__/{filename}.h", both at +4. As 
officiant I get to be the tiebreaker.

My thoughts so far:
* A bunch of longtime Python core devs cast their votes for 
"__clinic__": Nick, Terry, Stefan, Brett, Barry.  On the other hand, 
Antoine and Georg preferred "clinic".
* We have the precendent of __pycache__, where we cache 
machine-generated code that's the equivalent of code that in a file 
that's a sibling of the __pycache__ directory.
* But it's not a perfect metaphor.  For one, this directory will be 
checked in; __pycache__ directories should not be checked in.  For 
another, if you blow away a __pycache__ directory everything 
automatically works fine.  If you blow away a directory of Clinic 
generated code, you have to rebuild it by hand.  Until you do you've 
broken your build.
* We also have the precedent of "stringlib", a directory containing a 
bunch of unpleasant-to-look-at headers containing C code.  It's not 
machine-generated code.  But it is templatized code, so it's kind of 
compile-time generated on the fly if you squint at it.  And it is 
checked in.
* We also have the precedent of some machine-generated C code that is 
checked in in the Python tree: Python-ast.c, Python-ast.h. (Maybe one or 
two more?  I forget.)  None of these files have funny double-underscores 
prepended to their names.

Also:
If you only examine the people who voted +1 on "clinic", the sum of 
their votes on "__clinic__" is -0.5.
If you only examine the people who voted +1 on "__clinic__", the sum of 
their votes on "clinic" is +2.
Therefore, the people who voted for "__clinic__" are pretty tolerant of 
"clinic".  The people who voted for "clinic" are less tolerant of 
"__clinic__".

And finally:
The total positive votes for "clinic" were 6, and total for the minus -2.
The total positive votes for "__clinic__" were 7, and the minus -3.
So "__clinic__" seems slightly more divisive.


I'm leaning towards "clinic", primarily because of precedents in CPython 
trunk. But also because it makes it look more on-purpose and permanent.  
And because it's more aesthetically pleasing to look at.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140122/8fcdc7b8/attachment.html>


More information about the Python-Dev mailing list