Bug report

Bug description:

Starting with CPython 3.13, there is now a filelock.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 namedlock.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 forbuffer.h ->pybuffer.h in#31201.

Would a PR to rename the top-level include to e.g.pylock.h (either leavingcpython/lock.h alone, or renaming it too) be accepted? As far as I can tell, the file name oflock.h is an implementation detail of the public interfacePython.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 containonlyPython.h and no other files?

cc@colesbury and@vstinner who might be interested

CPython versions tested on:

3.13

Operating systems tested on:

Linux