On 2018-10-28, Benjamin Peterson wrote:
I don't think more or less API should be magically included based on whether Py_BUILD_CORE is defined or not.
If we want to have private headers, we should include them where needed and not install them. Really, Py_BUILD_CORE should go away. We should be moving away from monolithic includes like Python.h to having each C file include exactly what it uses, private or not.
It seems that is best practice (e.g. look at Linux kernel include file style). I wonder however what are the real benefits to having modular include files and directly using them as needed?
Pros for modular includes:
- speeds up build process if you have good dependency info in the build system. Right now, change Python.h and everything gets rebuilt. I'm not sure this is a huge advantage anymore.
- makes it clearer where an API is implemented?
- more work to include the correct headers
- build system dependency definitions are more complicated. Other systems generally have automatic dependancy generates (i.e. parse C files and find used includes).
A simple approach would be to introduce something like Python-internal.h. If you are a Python internal unit, you can include both Python.h and Python-internal.h. We could, over time, split Python-iternal.h into smaller modular includes.