@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 toint.to_bytes() and the incremental unpacking of 62 bit chunks usingPyNumber_And(),PyLong_AsLong() andPyNumber_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.