gh-117031: Add support for arbitrary C integer types for PyMemberDef.type#132550
gh-117031: Add support for arbitrary C integer types for PyMemberDef.type#132550serhiy-storchaka wants to merge 8 commits intopython:mainfrom
Conversation
…erDef.type Py_T_INTEGER(type) represents arbitrary C integer type.
serhiy-storchaka
requested review from
AA-Turner,
gpshead and
hugovk
as code owners
|
Hum, I prefer #117032 approach with one member type per C type. |
Misc/NEWS.d/next/C_API/2024-03-19-21-13-20.gh-issue-117031.0s3Ruq.rst
Outdated
Show resolved
Hide resolved
Co-authored-by: Stan Ulbrych <[email protected]>
|
Thanks @StanFromIreland. |
|
What do you think about using the lower byte for all |
|
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 Question: how to combine this with |
…' into structmember-types2
zooba
left a comment
zooba
left a comment
There was a problem hiding this comment.
LGTM, though off_t seems a bit of a weird one in all cases...
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. |
| {"T_CHAR", Py_T_CHAR, offsetof(test_structmembers, structmembers.char_member), 0, NULL}, | ||
| {"T_INT8", Py_T_INTEGER(int8_t), offsetof(test_structmembers, structmembers.int8_member), 0, NULL}, | ||
| {"T_UINT8", Py_T_INTEGER(uint8_t), offsetof(test_structmembers, structmembers.uint8_member), 0, NULL}, | ||
| {"T_XINT8", Py_T_INTEGER(int8_t)|Py_T_INTEGER(uint8_t), offsetof(test_structmembers, structmembers.xint8_member), 0, NULL}, |
There was a problem hiding this comment.
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?
5 participants
Py_T_INTEGER(type) represents arbitrary C integer type.
📚 Documentation preview 📚: https://cpython-previews--132550.org.readthedocs.build/