CPython 3.13: add _PyLong_New() and import some macros from pycore_hash.h

[skirpichev]

Turn on basic tests on 3.13

Closes #417

[codecov-commenter]

Codecov Report

Merging #441 (1edb036) into master (e094479) will not change coverage.
The diff coverage is n/a.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

@@           Coverage Diff           @@
##           master     #441   +/-   ##
=======================================
  Coverage   83.41%   83.41%           
=======================================
  Files          49       49           
  Lines       11797    11797           
  Branches     2205     2205           
=======================================
  Hits         9841     9841           
  Misses       1956     1956           

Files	Coverage Δ
src/gmpy2_hash.c	71.95% <ø> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[skirpichev]

I think we should decide which C-API we need. I would guess, something like mpz_limbs_read/mpz_limbs_write - i.e. access to the internal ob_digit array (see also this: cython/cython#5238 (comment)).

[casevh]

Thanks for fixing this.

Regarding a C-API that would be nice to have, I what do you think about proposing that CPython provides suitably renamed functions PyNewStyleInteger_FromOldStyleLong and PyNewStyleInteger_AsOldStyleLong? OldStyleLong wouldn't be a numeric type but rather a memory buffer that has the same layout as the pre-3.12 PyLong type.

[skirpichev]

@casevh, maybe something like this, yes. I still feel CPython people should try gmp-like API, as mentioned above.

I'll open an issue or start a discussion thread in d.p.o. Before, I'll look into more projects that may need this kind of stuff, besides gmpy2 and cython. Sage, perhaps? @oscarbenjamin, would you like to have this type of interface for python flint bindings? So far e.g. I see fmpz_get_intlong() do fmpz->int conversion using strings.

[casevh]

The existing PyLong uses a sign/magnitude format using either 15 or 30 bits per limb. GMP uses sign/magnitude with either 32 or 64 bits per limb. (At least on the platforms that are relevant to this discussion.) I think any sign/magnitude format that has a defined structure and relies on commonly available C types (i.e. uint32 or uint64 or equivalent) for the limbs would be fine. I wouldn't be surprised if CPython adopts 60 bits per limb in the future. to_bytes() and from_bytes() is a useful external interface but an arbitrary-precision 2s-complement format isn't the most efficient for conversion between two similar sign/magnitude formats.

…

On Tue, Oct 24, 2023 at 10:13 PM Sergey B Kirpichev < ***@***.***> wrote: @casevh <https://github.com/casevh>, maybe something like this, yes. I still feel CPython people should try gmp-like API, as mentioned above. I'll open an issue or start a discussion thread in d.p.o. Before, I'll look into more projects that may need this kind of stuff, besides gmpy2 and cython. Sage, perhaps? @oscarbenjamin <https://github.com/oscarbenjamin>, would you like to have this type of interface for python flint bindings? So far e.g. I see fmpz_get_intlong() do fmpz->int conversion using strings. — Reply to this email directly, view it on GitHub <#441 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMR235N2AD7HUSL6M4WYOTYBCNZPAVCNFSM6AAAAAA6LM6E5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZYGUZDMNJWHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[oscarbenjamin]

would you like to have this type of interface for python flint bindings?

Yes, I think so.

There is a PR here to try to optimise converting from a CPython int: flintlib/python-flint#64

Also efficient conversions between python-flint and gmpy2 would be good: flintlib/python-flint#56

What would be nice is if there was somehow a general API for doing this with any arbitrary precision integer type so that efficient conversions could be done for any of them rather than needing special casing for each type.

[skirpichev]

python/cpython#102471 seems to be the right upstream issue