-
-
Notifications
You must be signed in to change notification settings - Fork 30.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The C-API for Python to C integer conversion is, to be frank, a mess. #102471
Comments
We also need a few functions for querying and extracting the value of a Python int. We want to query its sign: int PyInt_IsNegative();
int PyInt_IsPositive();
int PyInt_IsZero();
int PyInt_Sign(); We want to import and export the digits of an integer, and to know how many digits there are. |
E.g. typedef struct _PyIntExportLayout {
uint8_t bits_per_digit,
int8_t word_endian,
int8_t array_endian,
uint8_t digit_size,
} PyIntExportLayout;
PyLongObject *PyInt_Import(PyIntExportLayout layout, size_t count, const void *data);
int PyInt_Import(PyLongObject *op, PyIntExportLayout layout, size_t count, void *data);
size_t PyInt_DigitCount(PyLongObject *op, uint8_t bits_per_digit);
const PyIntExportLayout PY_INT_NATIVE_LAYOUT; /* Use this when possible, for speed */ |
Hi. I'm the primary maintainer of I use
I like your Is Would there be a corresponding This is reversed from the current conversion direction. For I'll add another comment to the thread about the compact format. Thanks for all the effort in improving CPython. casevh |
Add PyLong_Export() and PyLong_Import() functions and PyLong_LAYOUT structure.
Add PyLong_Export() and PyLong_Import() functions and PyLong_LAYOUT structure.
I created #120390 for that. |
Add PyLong_Export() and PyLong_Import() functions and PyLong_LAYOUT structure.
I had plans to add |
This is relatively complex task, which is better suited to dedicated libraries. I would be rather surprised if some arbitrary precision math library lacks mpz_import/export-like functions. If on CPython side we will have a "view" of integers as an array of digits - the rest of work could do any math library. |
Then please used different names than |
Add PyLong_Export() and PyLong_Import() functions and PyLong_LAYOUT structure.
Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
I added APIs for that with 4c6dca8:
|
There is an open discussion for these functions: capi-workgroup/decisions#29 |
|
Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com> Co-authored-by: Steve Dower <steve.dower@microsoft.com> Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
The C-API has built up over 30 years, in a haphazard way. So, it is no surprise that it is a bit of a mess.
What makes it worse is that it is based around the C
long
type, which is varies in size between architectures and operating systems in odd ways.C
long
s are 32 bit on (almost?) all 32 bit machines, 64 bit on most 64 bit machines, except Windows when Clong
s are 32 bits on 64 bit machines. In other words, it is not a useful fixed size, likeint32_t
, nor does match the machine word size, likeintptr_t
.We need a more consistent API for converting from Python integers to C integers and back again.
We should support both 32 bit and word size C integers. 32 bit, because we often want to store 32 bit values to save space on 64 bit machines, or for portability. We also want to support word size integers for performance and ease of coding.
This means we want 4 functions (2 sizes, 2 directions) to convert between C and Python integers.
Currently we have:
PyLong_FromSsize_t
The C API has a function to convert Python ints to
intptr_t
, but it is missing efficient overflow handling.It also has a function with efficient overflow handling,
PyLong_AsLongAndOverflow
, but that returns along
.Here's what we want:
PyInt_AsInt32
PyInt_FromInt32
PyInt_AsSsize_t
PyInt_FromSsize_t
I'm using
PyInt
prefix, now that Python 2 is history. It makes it clearer what is the new API.Note that I'm not handling unsigned values. I think the extra bit of precision is not worth the complexity of a larger API.
And if we decide that they are, we can always add them later.
Linked PRs
The text was updated successfully, but these errors were encountered: