[C API] Don't define the `COMPILER` macro in the public C API

[vstinner]

On Windows, pyconfig.h defines the COMPILER macro. I propose to rename it to _Py_COMPILER to avoid name conflicts: see https://discuss.python.org/t/pre-pep-use-a-header-file-that-can-undefine-the-macros-defined-by-python-h/104784 for such conflict in practice.

Linked PRs

• gh-141341: Rename COMPILER macro to _Py_COMPILER on Windows #141342

[picnixz]

I personally think it's a bug but I'm not confident in changing this on bugfixes branches.

[vstinner]

I personally think it's a bug but I'm not confident in changing this on bugfixes branches.

There might be projects in the wild which use the COMPILER macro. It sounds unlikely since the macro is only defined on Windows. But I'm not comfortable to backport the change to stable branches.

[Locked-chess-official]

There might be projects in the wild which use the COMPILER macro. It sounds unlikely since the macro is only defined on Windows.

If the projects use the macros which were defined by "pyconfig.h" but don't start with "Py", it is undocumental so that if these projects crash, there is no wonder.
Considerring that may be there are the other macros that don't start with "Py" or "_Py" and conflict with other project, I wrote the package "python_undef" to handle it. I think that finally all of the macros that doesn't match PEP7 should be renamed.

[encukou]

See this message from Guido: https://discuss.python.org/t/finishing-the-great-renaming/54082/3

(FWIW, I've not followed up on that thread for a long time -- I'm waiting for the PEP-743 resolution so I don't need to do renames & deprecations/removal in two steps.)

[vstinner]

This problem exists since Python 2.7 (if not longer), so I don't think that there is an urgency to fix it in stable branches. There is a simple workaround: add #undef COMPILER after #include <Python.h>. I close the issue.