PEP 757: reject more ideas (#4017)
* keep PyLong_GetNativeLayout() function (was: open question) * reject mpz_import/export-like API
This commit is contained in:
parent
1490ed1ef5
commit
7ccefe1e2f
|
@ -388,23 +388,6 @@ There is no impact on the backward compatibility, only new APIs are
|
|||
added.
|
||||
|
||||
|
||||
Open Questions
|
||||
==============
|
||||
|
||||
* Should we add *digits_order* and *endianness* members to :data:`sys.int_info`
|
||||
and remove :c:func:`PyLong_GetNativeLayout()`? The
|
||||
:c:func:`PyLong_GetNativeLayout()` function returns a C structure
|
||||
which is more convenient to use in C than :data:`sys.int_info` which uses
|
||||
Python objects.
|
||||
* Currently, all required information for :class:`int` import/export is
|
||||
already available via :c:func:`PyLong_GetInfo()` or :data:`sys.int_info`.
|
||||
Native endianness of "digits" and current order of digits (least
|
||||
significant digit first) --- is a common denominator of all libraries
|
||||
for arbitrary precision integer arithmetic. So, shouldn't we just remove
|
||||
from API both :c:struct:`PyLongLayout` and :c:func:`PyLong_GetNativeLayout()` (which
|
||||
is actually just a minor convenience)?
|
||||
|
||||
|
||||
Rejected Ideas
|
||||
==============
|
||||
|
||||
|
@ -426,6 +409,46 @@ If later there are use cases for arbitrary layouts, new APIs can be
|
|||
added.
|
||||
|
||||
|
||||
Don't add :c:func:`PyLong_GetNativeLayout` function
|
||||
---------------------------------------------------
|
||||
|
||||
Currently, most required information for :class:`int` import/export is already
|
||||
available via :c:func:`PyLong_GetInfo()` (and :data:`sys.int_info`). We also
|
||||
can add more (like order of digits), this interface doesn't poses any
|
||||
constraints on future evolution of the :c:type:`PyLongObject`.
|
||||
|
||||
The problem is that the :c:func:`PyLong_GetInfo()` returns a Python object,
|
||||
:term:`named tuple`, not a convenient C structure and that might distract
|
||||
people from using it in favor e.g. of current semi-private macros like
|
||||
:c:macro:`!PyLong_SHIFT` and :c:macro:`!PyLong_BASE`.
|
||||
|
||||
|
||||
Provide mpz_import/export-like API instead
|
||||
------------------------------------------
|
||||
|
||||
The other approach to import/export data from :class:`int` objects might be
|
||||
following: expect, that C extensions provide contiguous buffers that CPython
|
||||
then exports (or imports) the *absolute* value of an integer.
|
||||
|
||||
API example::
|
||||
|
||||
struct PyLongLayout {
|
||||
uint8_t bits_per_digit;
|
||||
uint8_t digit_size;
|
||||
int8_t digits_order;
|
||||
};
|
||||
|
||||
size_t PyLong_GetDigitsNeeded(PyLongObject *obj, PyLongLayout layout);
|
||||
int PyLong_Export(PyLongObject *obj, PyLongLayout layout, void *buffer);
|
||||
PyLongObject *PyLong_Import(PyLongLayout layout, void *buffer);
|
||||
|
||||
This might work for the GMP, as this it has :c:func:`!mpz_limbs_read()` and
|
||||
:c:func:`!mpz_limbs_write()` functions, that can provide required "buffers".
|
||||
|
||||
The major drawback of this approach is that it's much more complex on the
|
||||
CPython side (i.e. actual conversion between different layouts).
|
||||
|
||||
|
||||
Discussions
|
||||
===========
|
||||
|
||||
|
|
Loading…
Reference in New Issue