Add `sys.abi_features` to make information about the interpreter ABI more accessible

My Py_mod_abi proposal doesn’t do what you want: it describes an extension, not the interpreter.
So we need something else.

I don’t think a C API for this makes much sense here. If the “bitness” is wrong, you can’t use any C API at all; if others don’t match you might be OK, depending on what you call.
So, let’s focus on something in sys that’s useful before the dll is loaded – e.g. to choose which DLL to build/install/load?

I don’t think the info should be based on flags. “Bitness” (sizeof(void*)) is a number – 4 or 8 bytes.
Also, we want to differentiate between a feature not being present/active, and the feature being unknown/unchecked. This will become important as future Python versions add new “flags”.
So, instead of a set of strings, I think this should be an object with attributes, in the style of sys.int_info and sys.thread_info. For example:

  • sys.abi_info.pointer_size (4 or 8), or pointer_bits (32 or 64)
  • sys.abi_info.Py_GIL_DISABLED (True/False)
  • sys.abi_info.Py_DEBUG

And perhaps all the other feature macros that define the build, e.g.:

  • sys.abi_info.Py_TRACE_REFS
  • sys.abi_info.Py_REF_DEBUG
  • sys.abi_info.Py_ENABLE_SHARED

And maybe more that describe the platform. How far do we want to go?

  • sys.abi_info.PY_BIG_ENDIAN
  • sizes of C primitive types, Py_ssize_t, wchar_t
  • sys.abi_info.HAVE_FORK
  • sys.abi_info.MS_WINDOWS
  • etc.
1 Like