gh-106320: Re-add some PyLong/PyDict C-API functions

[scoder]

Re-add _PyLong_FromByteArray(), _PyLong_AsByteArray(),_PyLong_GCD() and _PyDict_Pop() to the public header files.
They are used by third-party packages and there is no efficient replacement.

See #111140
See #111139
See #111262

• Issue: C API: Remove private C API functions (move them to the internal C API) #106320

[scoder]

@serhiy-storchaka @vstinner

[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.

[scoder]

add a nice public API for that

Oh, I'd be happy to. I see the revert as a way to make sure there *is* an API until we have something to replace it. For which, as Serhiy noted, the design and discussion can take arbitrarily long.

[scoder]

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.

[encukou]

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?

[encukou]

I still don't see the reason why this API was removed. PEP-387 says that it can be removed, not that it should.
We don't have a good replacement for this API. After we add that, it'll be time to start telling people to change their code.

I take @gvanrossum's comment on another issue as support for reverting the removal:

I strongly prefer revert over fix, for removed APIs that cause problems.

[vstinner]

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.