Repository navigation
<lock.h> filename is too generic #136759
Description
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
Activity
geofft commentedon Jul 18, 2025
I would very mildly argue this is a bug in that it's a regression: a third-party extension that built fine on Python 3.12 doesn't build on 3.13+ and there's no obvious way to make it build. But I don't feel super strongly about it. :)
colesbury commentedon Jul 18, 2025
Yes, let's rename
lock.htopylock.h. Let's also renamecpython/lock.htocpython/pylock.hfor consistency.gh-136759: rename `lock.h` to `pylock.h` (#137041)
pythongh-136759: rename `lock.h` to `pylock.h` (pythonGH-137041)
[3.13] gh-136759: rename `lock.h` to `pylock.h` (GH-137041) (#137075)
Revert "[3.13] pythongh-136759: rename `lock.h` to `pylock.h` (python…
kumaraditya303 commentedon Jul 28, 2025
Unfortunately the PR would have to reverted back for 3.13 and likely won't make it into 3.14 as @zooba explained at #137075 (comment)
[3.13] gh-136759: revert rename `lock.h` to `pylock.h` (GH-137041) (#…
python-afs: Compatibility with Python 3.13
pythongh-136759: rename `lock.h` to `pylock.h` (python#137041)
pythongh-136759: rename `lock.h` to `pylock.h` (python#137041)
StanFromIreland commentedon Sep 17, 2025
Closing as revert was completed and 3.14 backport was closed.