[Python-Dev] Rename Include/internals/ to Include/pycore/ (original) (raw)
Benjamin Peterson benjamin at python.org
Mon Oct 29 01:32:02 EDT 2018
- Previous message (by thread): [Python-Dev] Rename Include/internals/ to Include/pycore/
- Next message (by thread): [Python-Dev] Rename Include/internals/ to Include/pycore/
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sun, Oct 28, 2018, at 14:30, Victor Stinner wrote:
Le dim. 28 oct. 2018 à 21:50, Benjamin Peterson <benjamin at python.org> a écrit : > I don't think more or less API should be magically included based on whether PyBUILDCORE is defined or not. If we want to have private headers, we should include them where needed and not install them. Really, PyBUILDCORE 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.
I would prefer to avoid annoying with the backward compatibility. Currently, #include <Python.h> more or less provides you "anything" and I'm fine with that.
It doesn't break backward compatibility if you only make this required for new APIs.
I prefer to no put too many changes at once :-) My overall approach is to make sure that we don't leak functions by mistakes into the public API or into the stable API anymore. For example, if a function is really for the core, put it in pycore/. It will be more explicit when reviewing a change for example.
How does the current Include/internal/ directory fail at accomplishing your goal?
PyBUILDCORE is not only used to select which functions you get. PyBUILDCORE is also commonly used to get a macro instead of a function call, for best performances.
I think the macro and function versions should just have different names then.
- Previous message (by thread): [Python-Dev] Rename Include/internals/ to Include/pycore/
- Next message (by thread): [Python-Dev] Rename Include/internals/ to Include/pycore/
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]