[Python-Dev] .clinic.c vs .c.clinic (original) (raw)
Larry Hastings larry at hastings.org
Wed Jan 22 22:41:32 CET 2014
- Previous message: [Python-Dev] .clinic.c vs .c.clinic
- Next message: [Python-Dev] .clinic.c vs .c.clinic
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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>
- Previous message: [Python-Dev] .clinic.c vs .c.clinic
- Next message: [Python-Dev] .clinic.c vs .c.clinic
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]