I prefer separate header files, provided people outside of core always have one (presumably "Python.h") that should be included first and includes enough info to check which headers will be available (i.e. the version defs). Modifying preprocessor definitions for different Python versions, or having to set them before knowing what version is being used, seems more complicated. Cheers, Steve On 5/30/2022 8:26 PM, Brett Cannon wrote:
We discussed having leading underscores for this API tier, and it was decided that a leading underscore was preferred.
This did start a discussion, though, about whether we should control API access/opt-in via `#include` by having `.h` files that convey what API the user is opting into, or use `#define` to control what gets exposed via `Python.h`. The general feeling was that the header file idea is ideal, but it is a little extra work to transition to if you want to be compatible with older versions of Python that wouldn't have the header files (Victor's compatibility project could help here). The question for the team is whether separate header files makes sense to others, or would people prefer using `#define` and `Python.h` to control API access/opt-in?