My feeling (from looking at the implementation) is that in practice is doesn’t, but that the official story will be that it does.
(It would be really useful if it didn’t)
Unless explicitly documented otherwise, all C-API functions require the GIL to be held; this function even does potentially complex work like verifying what kind of object you passed in and generating an exception in case of a mismatch.
Actually, this specific function currently doesn’t do any checks, the notes in the documentation are just for future compatibility.
If you are willing to bypass the Stable API, you can just call the function without the GIL - as long as you aren’t in debug mode with asserts active, that should work. You do however introduce the potential for race conditions and your code is no longer guaranteed to be forward or backwards compatible. If you want this to also work when asserts are active you can just copy the definition of the function.
Thanks. I probably shouldn’t abuse it however tempting it is. Someone will end up running it with assets on in the end, for example.
I also don’t think I can copy the definition - I’m only trying to use it to get stable ABI support.
I think it will give the same offset each time (for each given type), so I think I can run it once on module import, cache the offset that it gives, and use the cached offset instead. That doesn’t feel like too much of an abuse.
But it’s still not using the Stable API as intended. You can do this, but then don’t be surprised if this breaks in some future version of CPython, meaning by doing this you lose any benefit you gain by following Stable API. And if you are in that situation, you can do far more invasive operations with higher reliability and speed.
Is this a question about the code that Cython generates or about a specific project that uses the C API?
The implicit context that @da-woods is a maintainer of Cython is not stated but I read the question here as being about clarifying the fuzzy contract between Cython and CPython rather than being about any particular project that may or may not choose to publish stable ABI wheels.
Yes - it’s a fair point. Although - I think for most users of the Stable ABI future compatibility isn’t the main benefit. Instead it’s the ability to cover many current Python versions now. There’s plenty of places where we’ve replaced unstable C API with unstable Python API (e.g. to instantiate code objects). Those will always compile but may not continue to work into the future and the expectation is to fix them as the break.
Yes it is. So in this case I’m trying to get pre-existing features (written long before the Stable ABI was even thought of) to work on the proposed Python 3.15+ Stable ABI. So there’s a balance between respecting the spirit of the Stable ABI and getting something that works now.
Currently my feeling is that caching the offset probably meets that.