Skip to content
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

PEP 757: Answer open questions #3980

Closed
wants to merge 2 commits into from

Conversation

vstinner
Copy link
Member

@vstinner vstinner commented Sep 19, 2024

Add "Don't add PyLong_GetNativeLayout() function" to Rejected Ideas.


📚 Documentation preview 📚: https://pep-previews--3980.org.readthedocs.build/

Add "Don't add PyLong_GetNativeLayout() function" to Rejected Ideas.
@skirpichev skirpichev self-requested a review September 20, 2024 01:32
Copy link
Member

@skirpichev skirpichev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think difference of PyLong_GetNativeLayout() vs PyLong_GetInfo() is a minor question and we don't need to rush here.

peps/pep-0757.rst Show resolved Hide resolved
peps/pep-0757.rst Show resolved Hide resolved
peps/pep-0757.rst Show resolved Hide resolved
Comment on lines +414 to +432
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 aribitrary precision integer arithmetic.

The problem is that this API is for the stable ABI and not only for
CPython, but for any Python implementation. For example, the JVM based
GraalPy uses Java's ``BigDecimal`` for "big" integers, which has
compatible internal representation: 4 bytes per digit, big-endian, most
significant byte is in the zeroth element.

People relying on CPython implementation details may assume CPython's
:c:struct:`PyLongLayout` without even querying it and will just use the
other APIs. Providing a convenient :c:func:`PyLong_GetNativeLayout`
function is a way to reduce the risk of relying on CPython
implementation details. By the way, the CPython native layout can also
evolve in future Python versions.

Copy link
Member

@skirpichev skirpichev Sep 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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 aribitrary precision integer arithmetic.
The problem is that this API is for the stable ABI and not only for
CPython, but for any Python implementation. For example, the JVM based
GraalPy uses Java's ``BigDecimal`` for "big" integers, which has
compatible internal representation: 4 bytes per digit, big-endian, most
significant byte is in the zeroth element.
People relying on CPython implementation details may assume CPython's
:c:struct:`PyLongLayout` without even querying it and will just use the
other APIs. Providing a convenient :c:func:`PyLong_GetNativeLayout`
function is a way to reduce the risk of relying on CPython
implementation details. By the way, the CPython native layout can also
evolve in future Python versions.
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 :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`.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still not sure if we should rush with this change. But if so, please take look on my edits.

I think the only arguments is: it's easy to use. (BTW, it seems (I did GH search) the PyLong_GetInfo() isn't used outside of CPython.)

@vstinner vstinner marked this pull request as draft September 23, 2024 11:50
@vstinner
Copy link
Member Author

I abandon my PR.

@vstinner vstinner closed this Sep 27, 2024
@vstinner vstinner deleted the pep757_remove_questions branch September 27, 2024 19:02
@skirpichev skirpichev mentioned this pull request Oct 3, 2024
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants