Bug report

Bug description:

Starting with CPython 3.13, there is now a file lock.h in the Python include directory (not in a further subdirectory). This causes problems when building with other projects or third-party libraries that already have a file named lock.h. See, for instance, mit-athena/python-afs#6 which is building Cython bindings to OpenAFS, which also has an include file of that same name. The compilation environment seems to search CPython's headers before OpenAFS's, meaning that #include <lock.h> now incorrectly picks up CPython's.

To be fair, there are a number of other generic header names too (object.h, import.h, warnings.h, etc.), and also to be fair, <lock.h> is too generic a name for OpenAFS to use, too, especially since it installs to /usr/include/lock.h. But many of the other Python includes have been around since the 1990s, and so people have already dealt with avoiding conflicts with those names, and conversely AFS's lock.h dates from the 1990s (or earlier) too.

It looks like something similar was done for buffer.h -> pybuffer.h in #31201.

Would a PR to rename the top-level include to e.g. pylock.h (either leaving cpython/lock.h alone, or renaming it too) be accepted? As far as I can tell, the file name of lock.h is an implementation detail of the public interface Python.h, and not itself a public interface.

On a more general note, is it worth trying to change things to make the installed header directory contain only Python.h and no other files?

cc @colesbury and @vstinner who might be interested

CPython versions tested on:

3.13

Operating systems tested on:

Linux