GeezerVison is showing github.com — Cannot include `cpython/Include/internal/pycore_optimizer.h` in C++ extension due to use of protected C++ keyword "not" · Issue #131331 · python/cpython
Cannot include cpython/Include/internal/pycore_optimizer.h in C++ extension due to use of protected C++ keyword "not" #131331Labels 3.14bugs and security fixesbugs and security fixesbuildThe build process and cross-buildThe build process and cross-buildinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)topic-JITtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error DescriptionBug report
Bug description:
The code in cpython/Include/internal/pycore_optimizer.h causing problems
typedef struct {
uint8_t tag;
bool not;
uint16_t value;
} JitOptTruthiness;CPython versions tested on:
3.14
Operating systems tested on:
macOS
Linked PRs
Activitytim-stephenson commented on Mar 16, 2025 picnixz commented on Mar 16, 2025 AFAIK, cpython/Include/internal/pycore_optimizer.h is not meant to be included directly, nor from an extension module as it's internal. Is there an issue because of some indirect includes if one uses #include "Python.h"? or is this only caused when one tries to include that specific header?
EDIT: I'm marking it as a release blocker if this implies that C++ extensions cannot be built anymore but if it's because of internal includes, then we can remove the label. picnixz commented on Mar 16, 2025 tim-stephenson commented on Mar 16, 2025 picnixz commented on Mar 16, 2025 I think it doesn't hurt on our side if just use something else than not. We can use not_. I'll make a PR for that.
EDIT: However, I would like to mention that using internal headers is at one's own risk, though, in this case, the fix on our side is easy. markshannon commented on Mar 18, 2025 I would argue that allowing internal headers to be accessed in third-party code does hurt us.
Accessing the internals without a clear understanding of the necessary invariants can leave the VM in a broken state.
The resulting issues can be hard to debug and can consume of a lot of our time.
Regarding the numba issue. If there is a feature that is needed but does not have a public API, then we need to tell extension developers to submit a feature request, like this one from the Cython developers. picnixz commented on Mar 18, 2025
I would argue that allowing internal headers to be accessed in third-party code does hurt us.
Yes, in general, that's what I would say. But if the fix is simple enough and if it's easier than to make a feature request, then I'd say let's do it on our side. But I agree that I would prefer not to worry about compatibilty with projects including internal headers.
Would you be willing to consider accepting my fix for this specific issue though?
MetadataMetadata3.14bugs and security fixesbugs and security fixesbuildThe build process and cross-buildThe build process and cross-buildinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)topic-JITtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error DevelopmentNo branches or pull requestsIssue actions
|