Skip to content

gh-137210: Add a struct, slot & function for checking an extension's ABI #137212

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 14 commits into
base: main
Choose a base branch
from

Conversation

encukou
Copy link
Member

@encukou encukou commented Jul 29, 2025

Comment on lines +329 to +330
(except if :c:macro:`Py_LIMITED_API` is ``3``; use
:c:expr:`Py_PACK_VERSION(3, 2)` in that case).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems easier for us to just check this on our side than to expect users to get it right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And isn't the legacy value 1 rather than 3?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would you encode being compatible with both GIL and FT?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we just... update them?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To what? Py_VERSION_HEX? Or tell the RM to increment on release?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are all of these warnings about? Does _Py_PACK_VERSION do something funky?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No idea. I'll need to check on a Windows box.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't able to figure it out. Something seems to be compiling modsupport.h outside of Python.h -- that is, without pymacro.h being included first: I get an error if I add this before the line:

#ifndef Py_PYMACRO_H
#error this should not happen
#endif

The error is currently quite impenetrable to me:

       ResourceCompile:
         C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\x86\rc.exe /D "ORIGINAL_FILENAME=\\\"python315_d.dll\\\"" /D FIELD3=100 /D _DEBUG /l"0x0409" /IC:\Users\encukou\dev\cpython\PC /IC:\Users\encu 
         kou\dev\cpython\Include /IC:\Users\encukou\dev\cpython\PCbuild\obj\315amd64_Debug\pythoncore\ /nologo /fo"C:\Users\encukou\dev\cpython\PCbuild\obj\315amd64_Debug\pythoncore\python_nt.res" ..\PC\pyth 
         on_nt.rc
     3>C:\Users\encukou\dev\cpython\Include\modsupport.h(98): error RC2188: C:\Users\encukou\dev\cpython\PCbuild\obj\315amd64_Debug\pythoncore\RCa08340(52) : fatal error RC1116: RC terminating after preproce
       ssor errors [C:\Users\encukou\dev\cpython\PCbuild\pythoncore.vcxproj]

     3>Done Building Project "C:\Users\encukou\dev\cpython\PCbuild\pythoncore.vcxproj" (Build target(s)) -- FAILED.

@encukou encukou requested a review from AA-Turner as a code owner August 7, 2025 11:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants