On Mon, 30 May 2022 12:53:57 -0700 Guido van Rossum firstname.lastname@example.org wrote:
I would love to see header files used for this -- while I know there is a long tradition of feature-flags that must be #defined by the user before #including a header in order to affect what the header exports (or not!), 30 years later I still find that approach pretty unintuitive.
Agreed that #defining a flag before #including a header is a brittle approach. If something else included the header before you set your #define, then include guards can prevent you from seeing any effects.
This is a common issue in Windows land with the godawful Windows.h header file.
But yes, it's going to be a complex transition.
On Mon, May 30, 2022 at 12:30 PM Brett Cannon email@example.com 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? _______________________________________________ Python-Dev mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://firstname.lastname@example.org/message/Q5JU5YKG... Code of Conduct: http://python.org/psf/codeofconduct/