Repository navigation
[C API] Add PyLong_FromInt64() and PyLong_ToInt64() #120389
Description
Activity
- added a commit that references this issue
on Jun 12, 2024 This conflicts with the interface of other
PyLong_As*functions. If you want to use different convention, it is better to use different names.There are some design questions:
- Should all these functions be separate functions or aliases of other functions with the same size and signness?
- Which functions should call
__index__()(and therefore release the GIL) and which should be PyLong only? - How to handle negative values for unsigned types?
- How to handle overflow?
- It is worth to make these function compatible with the
O&format unit inPyArg_Parse-- returning 1 for success and 0 for failure.
See also #117031.
This conflicts with the interface of other PyLong_As* functions. If you want to use different convention, it is better to use different names.
We can use
PyLong_To*()convention. What do you think?How to handle negative values for unsigned types?
They must fail with ValueError (or OverflowError).
How to handle overflow?
Raise a OverflowError.
It is worth to make these function compatible with the O& format unit in PyArg_Parse -- returning 1 for success and 0 for failure.
New API should follow new guidelines: 0 on success, -1 on error: https://devguide.python.org/developer-workflow/c-api/index.html#guidelines-for-expanding-changing-the-public-api
- I prefer
UInttoUintsince there are two words: Unsigned INTeger.
bikeshedding: We have
PyLong_AsSsize_tinstead ofPyLong_AsSSize_tfor ssize_t/Py_ssize_t, so I personally preferUinttoUIntbecause of consistency.- I prefer
We can use
PyLong_To*()convention. What do you think?I was going to suggest the same. Or include
Convertin the name.New API should follow new guidelines: 0 on success, -1 on error: https://devguide.python.org/developer-workflow/c-api/index.html#guidelines-for-expanding-changing-the-public-api
Then we will end with two sets of functions with the same signature, but opposite meaning of the returned value. I am going to propose to make
PyArg_Parse-compatible converters public.- changed the title
[-][C API] Add PyLong_FromInt64() and PyLong_AsInt64()[/-][+][C API] Add PyLong_FromInt64() and PyLong_ToInt64()[/+]on Jun 17, 2024 I renamed the functions to
PyLong_ToInt64()andPyLong_ToUInt64().- added 5 commits that reference this issue
on Jun 19, 2024 There are some design questions: (...)
You can now check #120390 implementation, especially the test suite, to get answers to your questions.
I created capi-workgroup/decisions#32 "Add PyLong_FromInt64() and PyLong_ToInt64()" in the C API WG Decisions project.
Feature or enhancement
I propose to add functions to convert <stdint.h> integers to/from Python int objects:
Notes:
UInttoUintsince there are two words: Unsigned INTeger.Tofunctions don't return the result, but a status: 0 on success, -1 on error (with an exception set). It's to solve the C API Problem #1: "Ambiguous return values". PyLong_AsLong() returns -1 on success and on error (with an exception set).Related discussion: Avoid C-specific Types.
Linked PRs