@serhiy-storchaka @vstinner

I would prefer to take it as an opportunity to add a nice public API for that. In the meanwhile (until next alpha release), you can just use the internal C API.

Just for the record, I micro-benchmarked _PyLong_AsByteArray() against the C-API call to int.to_bytes() and the incremental unpacking of 62 bit chunks using PyNumber_And(), PyLong_AsLong() and PyNumber_Rshift(). The code complexity increases substantially from first to last in that order.

# int.to_bytes()
$ python3.10 -m timeit -s 'from intbench import i128_from_py' 'i128_from_py(2**126)'
200000 loops, best of 5: 1.06 usec per loop

# incremental unpacking
$ python3.10 -m timeit -s 'from intbench import i128_from_py' 'i128_from_py(2**126)'
500000 loops, best of 5: 693 nsec per loop

# _PyLong_AsByteArray()
$ python3.10 -m timeit -s 'from intbench import i128_from_py' 'i128_from_py(2**126)'
500000 loops, best of 5: 504 nsec per loop

This suggests to me that making _PyLong_AsByteArray() public is worth it. The replacements are just horrible to implement, and the "obvious replacement" is really slow.

I would prefer adding these back, so that we can take our time to add a proper replacement.
Or, Victor, do you think you can design and add a good replacement in time for the next alpha?

Victor, do you think you can design and add a good replacement in time for the next alpha?

Yes, I plan to add public APIs to replace these useful functions. I created multiple issues to track that: issues listed in the PR description.