On 1/22/2014 4:41 PM, Larry Hastings wrote:
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.
Yep.
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.
I think you nicely summarized the various thoughts on 'clinic/' versus
'__clinic__'.
--
Terry Jan Reedy
_______________________________________________
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/archive%40mail-archive.com
