gh-137210: Add a struct, slot & function for checking an extension's ABI #137212
Conversation
| (except if :c:macro:`Py_LIMITED_API` is ``3``; use | ||
| :c:expr:`Py_PACK_VERSION(3, 2)` in that case). |
There was a problem hiding this comment.
Seems easier for us to just check this on our side than to expect users to get it right?
There was a problem hiding this comment.
And isn't the legacy value 1 rather than 3?
There was a problem hiding this comment.
Well, users should use PyABIInfo_DEFAULT_ABI_VERSION or PyABIInfo_VAR -- those are our side too.
I prefer the data to be simpler, but if you want, we can keep the exception in.
The legacy value is 3. (Not that it matters that much; it's always compared to a Python version.)
| Specifies ABI specific to a particular build of CPython. | ||
| Internal use only. | ||
|
|
||
| Free-threading compatibility -- one of: |
There was a problem hiding this comment.
We're still planning to get rid of these options once FT is merged, right? Maybe we ought to use abiflags here (i.e. a string) instead, for future extensibility? This isn't going to be checked anywhere that it needs to be bitflags.
There was a problem hiding this comment.
How would you encode being compatible with both GIL and FT?
There was a problem hiding this comment.
IMO, we can remove them when there are no GIL-only extensions around any more. That would be a lot of time after FT is the only option.
| @@ -56,55 +56,14 @@ PyAPI_FUNC(int) PyModule_ExecDef(PyObject *module, PyModuleDef *def); | |||
|
|
|||
| #define Py_CLEANUP_SUPPORTED 0x20000 | |||
|
|
|||
| /* The API and ABI versions are left for backwards compatibility. | |||
There was a problem hiding this comment.
To what? Py_VERSION_HEX? Or tell the RM to increment on release?
There was a problem hiding this comment.
I don't think it particularly matters, it could be inferred from Py_LIMITED_API if that's set.
It's just an arbitrary value with a purpose that isn't really going away, so deprecating them seems unnecessary when we could just keep using them for their intended purposes (and ignore that they didn't get updated for a large number of ABI changes).
There was a problem hiding this comment.
Oh, do you want to use an int instead of the PyABIInfo struct?
I don't think reusing these would buy us much.
These version numbers are currently used in PyModule_Create and PyModule_FromDefAndSpec, i.e. single-phase init (legacy) and manual module object creation (where version checking isn't that useful).
There was a problem hiding this comment.
Or just use it as one of the values that goes into the struct. We can include more information if needed, it just seems like a waste to declare these names as irrelevant when we could just as easily make them relevant.
There was a problem hiding this comment.
We can make them relevant, but what relevance should they have?
We switched to a versioning scheme where Py_VERSION_HEX gives you all the necessary info. Dropping these extra numbers is a win.
If we can find a use case in the future, that's what the versioning in PyABIInfo is for.
| @@ -134,6 +93,72 @@ PyAPI_FUNC(PyObject *) PyModule_FromDefAndSpec2(PyModuleDef *def, | |||
|
|
|||
| #endif /* New in 3.5 */ | |||
|
|
|||
| /* ABI info & checking (new in 3.15) */ | |||
| #if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= _Py_PACK_VERSION(3, 15) | |||
There was a problem hiding this comment.
What are all of these warnings about? Does _Py_PACK_VERSION do something funky?
There was a problem hiding this comment.
No idea. I'll need to check on a Windows box.
Co-authored-by: Steve Dower <steve.dower@microsoft.com>
See the issue.
📚 Documentation preview 📚: https://cpython-previews--137212.org.readthedocs.build/