gh-117031: Add support for arbitrary C integer types for PyMemberDef.type

[serhiy-storchaka]

Py_T_INTEGER(type) represents arbitrary C integer type.

• Issue: Support more integer types in PyMemberDef #117031

---

📚 Documentation preview 📚: https://cpython-previews--132550.org.readthedocs.build/

[vstinner]

Hum, I prefer #117032 approach with one member type per C type.

[serhiy-storchaka]

Thanks @StanFromIreland.

[encukou]

What do you think about using the lower byte for all PyLong_AsNativeBytes flags (not just signedness), as @zooba proposed?

[serhiy-storchaka]

Perhaps Py_ASNATIVEBYTES_UNSIGNED_BUFFER can be used without Py_ASNATIVEBYTES_REJECT_NEGATIVE (but not opposite). All other flags do not make sense here. Endianess is always native, there is no reason to not support __index__.

Question: how to combine this with Py_INTEGER()?

[zooba]

LGTM, though off_t seems a bit of a weird one in all cases...

[zooba]

Perhaps Py_ASNATIVEBYTES_UNSIGNED_BUFFER can be used without Py_ASNATIVEBYTES_REJECT_NEGATIVE (but not opposite).

If you use UNSIGNED_BUFFER without REJECT_NEGATIVE, then you can get data in the most significant bit for a large positive int rather than being guaranteed a sign bit. It's like a normal C cast.

Without UNSIGNED_BUFFER but with REJECT_NEGATIVE, you're guaranteed that the top bit is going to be 0, because it must be the sign bit and you'll never have a negative value, so you have 1 fewer bits of data.

If a normal C cast is not appropriate here (and I don't think it is), then for unsigned types you'll want both flags and for signed types you'll want neither.

[vstinner]

I don't get the use case of this weird type. If you consider that it's important to support it, can you at least document it?

[github-actions]

This PR is stale because it has been open for 30 days with no activity.