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

Core Development
1

I’d like to draw attention to Issue 133143, which adds a new attribute to the sys module of the standard library.

This suggested change grew out of the perceived need to make information about ABI characteristics of the interpreter more easily available.
For example, currently it is not possible to determine whether the interpreter is built for a 32-bit or 64-bit architecture on platforms where both kinds of binaries are supported, such as Windows.
Furthermore, determining some aspects of the ABI, like free-threadedness or the presence of debug features is cumbersome and can vary between platforms.

To address these issues and facilitate easy determination of such characteristics the new attribute is introduced.

1 Like
2

More precisely, it’s not possible to determine between AMD64 and ARM64 on platforms where both kinds are supported, such as Windows.[1]

I think this is a good idea, but want to see the values properly specified (a couple to start with, and policies/guidance on adding/removing them later).

  1. The current way is to inspect sys.winver, which is fine, but it’s not really formalised. ↩︎

3

I think I know the reason, but, could you explain why these are flags, rather than key-value pairs?
Under the current scheme, a (non-CPython) implementation could use 16-bit or 128-bit. One could argue that a better model would use a dict entry (or attribute) like bitness = 32 or pointer_bits = 64.

I’m a bit worried that the scope isn’t well-defined.
Does little_endian/big_endian (sys.byteorder) belong here?

Or some more obscure ABI-affecting flags, like HAVE_FORK? (The real question here being: why not?)

For context, I’ve been thinking about adding some abi_info object with a somewhat bigger scope. One possibility would be that we add that, and packaging specs could cherry-pick pieces to export as environment marker flags. This would also be more backwards compatible: if something would need to be added later, packaging tools could easily use a non-abi_info workaround on older Pythons.

Hmm, writing that made lean more toward CPython exposing the needed info in a straightforward and supported way, but not necessarily as a set of flags.

4

Isn’t sys.maxsize idiomatically used for this?

bits = 64 if sys.maxsize > 2**32 else 32
1 Like
5

That doesn’t work for all interpreters like e.g. GraalPy, which is a 64bit VM but (due to the Java base) has a maximum of 31bits for its array sizes.

Packaging has changed their detection code to match what’s in platform.py using struct.calcsize("P") == 4.

I feel that’s obscure enough to get right to warrant a better place to query this.

4 Likes