You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Freethreading interpreter will attempt to import unsupported stable ABI extension modules #120901
Compile a stable ABI extension module with the filename "something.abi3.so" (or .pyd on Windows)
Run python -c "import something"
A freethreading build will attempt to import the extension module, even though it explicitly isn't compatible with the stable ABI. This (unsurprisingly) leads to a crash.
Tested on beta 3.13.0b2 (but a quick search didn't find relevant changes after that)
The abi3.so or .pyd suffixes aren't enough to identify supported Python versions. For example, you can have an ABI 3.14+ library with abi3.so and Python 3.5 will load it and crash.
I think we should probably refuse to load something.abi3.so in the free-threaded build, but I don't think we can do that for something.pyd on Windows (nor something.so on Unix).
@da-woods, can you provide more context on how you ran into this?
but I don't think we can do that for something.pyd on Windows (nor something.so on Unix).
I didn't intend to propose this. I the sentence "(or .pyd on Windows)" was a bit ambiguous and I only meant ".abi3.pyd on Windows".
can you provide more context on how you ran into this?
I was testing an in-place no-gil build of Cython and hadn't properly cleared up all the .so files before trying to test something else with free-threading Python. This is obviously something you're more likely to run into when doing ad-hoc development of extension modules rather than using pre-compiled wheels.
I don't think Windows uses .abi3.pyd as a suffix, just .pyd for both ABI 3 shared libraries and unversioned shared libraries.
I was testing an in-place no-gil build of Cython...
That makes sense. I think that's related to #121103, where the free-threaded and default builds both use the same lib/python3.13 directory (and I think we should change that).
That checks will only print a better error message before the crash
PEP 803 (draft) adds some more: making Py_mod_abi mandatory in the future, and explicitly saying that it's the responsibility of users (and their tools) to not put incompatible extensions on PYTHONPATH.
None of that is a fix, of course, but all three (and #121103) should help ad-hoc development :)
Activity
colesbury commentedon Jun 24, 2024
The
abi3.soor.pydsuffixes aren't enough to identify supported Python versions. For example, you can have an ABI 3.14+ library withabi3.soand Python 3.5 will load it and crash.colesbury commentedon Jun 27, 2024
I think we should probably refuse to load
something.abi3.soin the free-threaded build, but I don't think we can do that forsomething.pydon Windows (norsomething.soon Unix).@da-woods, can you provide more context on how you ran into this?
da-woods commentedon Jun 27, 2024
I didn't intend to propose this. I the sentence "(or .pyd on Windows)" was a bit ambiguous and I only meant ".abi3.pyd on Windows".
I was testing an in-place no-gil build of Cython and hadn't properly cleared up all the .so files before trying to test something else with free-threading Python. This is obviously something you're more likely to run into when doing ad-hoc development of extension modules rather than using pre-compiled wheels.
colesbury commentedon Jun 27, 2024
I don't think Windows uses
.abi3.pydas a suffix, just.pydfor both ABI 3 shared libraries and unversioned shared libraries.That makes sense. I think that's related to #121103, where the free-threaded and default builds both use the same
lib/python3.13directory (and I think we should change that).kumaraditya303 commentedon Nov 6, 2025
I think this is addressed by check added in #137957, @encukou?
encukou commentedon Nov 6, 2025
That checks will only print a better error message before the crash
PEP 803 (draft) adds some more: making
Py_mod_abimandatory in the future, and explicitly saying that it's the responsibility of users (and their tools) to not put incompatible extensions on PYTHONPATH.None of that is a fix, of course, but all three (and #121103) should help ad-hoc development :)
✨ feat(build): support free-threaded Python wheels (#307)