I pushed many changes. I moved most of the Py_BUILD_CORE code out of Include/ header files.
Le jeu. 1 nov. 2018 à 02:35, Eric Snow email@example.com a écrit :
On the one hand dropping redundancy in the filename is fine. On the other having the names mirror the public header files is valuable.
Current content of Include/internal/:
pycore_accu.h pycore_atomic.h pycore_ceval.h pycore_condvar.h pycore_context.h pycore_getopt.h pycore_gil.h pycore_hamt.h pycore_hash.h pycore_lifecycle.h pycore_mem.h pycore_pathconfig.h pycore_state.h pycore_warnings.h
I tried to find a kind of consistency. For example, there was Include/internal/mem.h vs Internal/pymem.h.
I renamed Include/pyatomic.h to Include/internal/pycore_atomic.h. Previously, the file had a "py" prefix to avoid the risk of having an <atomic.h> header file coming from somewhere else, but now with the "pycore_" prefix, it's very unlikely.
I renamed Include/accu.h to Include/internal/pycore_accu.h.
There are 4 header files which are in Include/ and Include/internal/ and the one in internal has no "py":
* pyhash.h and pycore_hash.h * pylifecycle.h and pycore_lifecycle.h * pymem.h and pycore_mem.h * pystate.h and pycore_state.h
I wrote a PR to rename these 4 header files: https://github.com/python/cpython/pull/10275
How about leaving the base names alone and change the directory to "pyinternal"?
The name of the directory doesn't matter to fix the #include bug when two header files have the same filename in two directories (especially when Include/ and Include/internal/ have the same filename).
Note: Since I added Include/internal/ to the search paths for header files, the name of the directory doesn't matter anymore. C code only uses the filename without "internal/" to include an internal header: #include "pycore_mem.h". Benjamin and you were opposed to change the name, so I kept "Include/internal/".