PEP 757: Rename endian to endianness

[vstinner]

• Remove the "Optimize small integers" section.
• Elaborate on PyLong_GetNativeLayout() validity.
• Mention PyLong_FreeExport() in the specification.

---

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

[vstinner]

@skirpichev: I don't think that the "Optimize small integers" section is still relevant since we added PyLongExport.value. What do you think?

[vstinner]

Rename endian to endianness

That's a request of @pitrou.

[skirpichev]

On Wed, Sep 18, 2024 at 01:48:26AM -0700, Victor Stinner wrote: ***@***.***: I don't think that the "Optimize small integers" section is still relevant since we added PyLongExport.value. What do you think?

I think it's still relevant for writing API. The GMPy_PyLong_From_MPZ() has special case with PyLong_FromLong().

[skirpichev]

On Wed, Sep 18, 2024 at 01:48:48AM -0700, Victor Stinner wrote: Rename endian to endianness That's a request of ***@***.***

I'm still unsure about fate of PyLongLayout and co, but it's good to keep things in sync with the pr. I'm planning to format API sections as sphinx docs from the pr.

[skirpichev]

@vstinner, maybe you can update benchmarks for export? See python/cpython#121339 (comment). With latest changes, something like third one is relevant.

[vstinner]

I think it's still relevant for writing API. The GMPy_PyLong_From_MPZ() has special case with PyLong_FromLong().

Ok, but is it worth it to mention it in the PEP? The gmpy code uses GMP functions for that: mpz_fits_slong_p().

I'm planning to format API sections as sphinx docs from the pr.

I don't understand. Do you want to modify this PR?

@vstinner, maybe you can update benchmarks for export?

I updated benchmarks with results that I got locally.

My benchmark doesn't look very reliable since the reference timings changed as well. But well, it should give an idea of the performance.

[skirpichev]

The gmpy code uses GMP functions for that: mpz_fits_slong_p().

Yes, but the point is to fallback on PyLong_FromLong() to avoid generic code.

Do you want to modify this PR?

No, it's big enough:)

My benchmark doesn't look very reliable since the reference timings changed as well.

I don't expect that there are some recent changes in gmpy2, that might affect timings on this area.

[skirpichev]

Mark Shannon asked to include also reference code in some form. We can, for example, provide hyperlinks to github.

mpz_set_PyLong:
https://github.com/aleaxit/gmpy/blob/9177648c23f5c507e46b81c1eb7d527c79c96f00/src/gmpy2_convert_gmp.c#L42-L69

GMPy_PyLong_From_MPZ:
https://github.com/aleaxit/gmpy/blob/9177648c23f5c507e46b81c1eb7d527c79c96f00/src/gmpy2_convert_gmp.c#L128-L156

[vstinner]

Yes, but the point is to fallback on PyLong_FromLong() to avoid generic code.

I restored the "small integer" section, but rephrased it only for the import API.

[vstinner]

Mark Shannon asked to include also reference code in some form. We can, for example, provide hyperlinks to github.

I let you create a PR if you want to add that.