On Sun, Oct 28, 2018, at 14:30, Victor Stinner wrote: > Le dim. 28 oct. 2018 à 21:50, Benjamin Peterson <benja...@python.org> a écrit > : > > 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. > > 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? > > Py_BUILD_CORE is not only used to select which functions you get. > Py_BUILD_CORE 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. _______________________________________________ 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
