alt Hacker NewsMy headline feature is the new “abi3t” stable ABI for the free-threaded build. While Petr Viktorin did most of the CPython implementation, I’ve been trying to make sure ecosystem support is ready. It’s been a rewarding but quite challenging project to make sure everything is working. There were some late nights leading up to the beta1 release when we found a Windows-specific issue that needed a fix.
I’m particularly proud that the cryptography project is already shipping a single abi3.abi3t wheel for each platform on Python 3.15 or newer. The GIL-enabled build and free-threaded build can both use the same wheel now, because PyObject is opaque.
If you want to learn more about this, I gave a talk at EuroPython this year on Python’s ABI and the road to building and releasing abi3t today. See https://youtu.be/An8lO29SxXE.
Replies
Are you aware of specific issues remaining in pyo3’s abi3t support or is that good to go?
Came here to say this. A stable ABI will mean that libraries can make a single free-threaded build that'll last at least a couple of Python versions into the future.
As a maintainer of a Python module that uses abi3 now, thank you!
Just one question: any plans to promote APIs like PyUnstable_EnableTryIncRef() and PyUnstable_TryIncRef() into the limited API? So far we have found that these APIs are necessary to implement the weak-valued caches we've always used in the past: https://github.com/protocolbuffers/protobuf/blob/6559a9f9622...