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.
I agree. > 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? Cons: - 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. _______________________________________________ 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