This idea is to use pycore_pyconfig.h to avoid the macros not start with Py or _Py go into the user codes. Maybe it can reduce the amount of modifications in the issue #157695.
The private config macros will be moved to this header file. When Py_BUILD_CORE was defined it will be included. Otherwise user cannot include this file.
Someone might be using the macros. Hiding them would be a backwards-incompatible change.
Breaking the relating of the private details is not backwards-incompatible. I think that who are using them should change it unless they have strong reason. In that case it is needed to redesign the macro as a public api.
Things that begin with Py (no underscore) are not private. They’re just owned by Python by virtue of being in the Py namespace.
See the C API compatibility policy for more details.
Also even removing private symbols can be very disruptive and must be done carefully. Historically people were very liberal about using exposed internals and many important C extensions are in maintenance mode.
The macros in this idea often be HAVE_* or SIZEOF_* and so on. The reason to hidden them is that they don’t match the rule that must start with Py, _Py, PY or _PY
Just based on a very quick search, Cython uses HAVE_HYPOT and HAVE_STDARG_PROTOTYPES so you would break existing code with this change.
I’m sure we could cope and work around it if it was really necessary. But that forces people to update to a newer version of Cython. And I’m sure we aren’t the only ones using these macros.
Edit: and a couple of the SIZEOF_ macros too.
This changing will only happen in the main branch (3.16), so “forces people to update to a newer version of Cython” is inevitable on newer python.
The question is “why should use them”. Answering it is helpful for designing the appropriate public names.
No, the question is “what is the benefit of making the change?” The cost is fairly clear (although you may disagree on the importance of the cost). But without a clear benefit, any cost is too much.
Now, just for the issue given in the topic, if it is needed to open lots of PRs to rename all of the names given, it costs too much time and resource. (Just according to the several PRs, I estimate pessimistically that there will be millions of lines changing and about a year to finish).
Rename all of the macro is cost, so I use this header file to split them for least-exposing to clear non-standard macros.
I just added Tools/build/check_capi_macros.py to the main branch to fail if a new macro which doesn’t start with Py prefix is added to the Python C API. It would be nice to stop adding new “invalid” macros to the public C API (for the internal C API, we have more freedom).
The script ignores existing “invalid” macros from the new file Tools/build/check_capi_macros_ignored.txt. The Python 3.16 C API has 797 “invalid” macros (macros which don’t start with Py prefix). Removing these 797 macros from the Python C API at once is very likely to break a large number of C/C++ extension. @da-woods already identified that Cython extensions will be be affected.
I don’t see much value to touch (remove/rename) existing “invalid” macros. It’s too risky. But we can do better since Python 3.16 by no longer adding new “invalid” macros.
If someone really wants to do something with invalid macros, I would suggest to experiment changes only in the limited C API which is more strict. For example, I modified the limited C API to no longer include system header files:
<errno.h>, <stdio.h> and <stdlib.h><ctype.h> and <unistd.h>I also tried to make these change to the general Python C API, and it broke C extensions which expect these system headers to be included by <Python.h>.