C API: Consider adding a public PyLong_GCD() function

[vstinner]

Feature or enhancement

The private _PyLong_GCD() function was removed in Python 3.13: see PR #108429.

@scoder asked what is the intended replacement for _PyLong_GCD(). I suppose that the replacement is to call math.gcd().

Is it worth it to add a public PyLong_GCD() function to the C API? Is it commonly used?

A code search for _PyLong_GCD is PyPI top 5,000 projects found 0 projects using it.

@scoder: What is your use case for _PyLong_GCD()? Using math.gcd() doesn't solve your use case?

Linked PRs

• gh-111139: Optimize math.gcd(int, int) #113887

[vstinner]

cc @serhiy-storchaka @mdickinson

[scoder]

I use the function in quicktions, a fast reimplementation of the fractions.Fraction data type.

Like the original, it depends heavily on the GCD performance. I tried calling math.gcd() instead and it's over 7% slower in the telco benchmark on Python 3.10/3.11.

If there is no reason for this specific function to be removed from the API, I'll simply ask to have it back. It's there, it's unlikely to change, so there is no reason not to expose it.

[serhiy-storchaka]

If direct call of _PyLong_GCD() makes the code 7% faster than using math.gcd(), it is perhaps not worth. Note that many methods of builtin types (like str.upper()) are not exposed in the C API. General Python object or method call API is the way to use them.

[scoder]

If direct call of _PyLong_GCD() makes the code 7% faster than using math.gcd(), it is perhaps not worth.

If no public function will be added, then please put the old function back in. There was no reason to remove it and break existing code.

[vstinner]

The rationale for the removal was given in the issue.

[scoder]

The rationale for the removal was given in the issue.

No, it really wasn't. But I was able to reverse engineer some reasoning based on hints that you gave in discussions that were linked in random comments spread across the huge ticket. I'm perfectly fine with removing "private" and "private by convention" APIs when they get in the way or when they cannot easily be kept alive. But that was not part of the reasoning.

I do not understand why existing code must be broken without need. And there is really no reason at all why this specific function cannot be public. It's literally just a single line in longobject.h that didn't hurt anyone for the last eight years, and that would happily continue to not get in the way if it hadn't been removed. Now it does get in the way, simply by no longer being there.

If direct call of _PyLong_GCD() makes the code 7% faster than using math.gcd(), it is perhaps not worth.

quicktions is all about being fast. That's the whole point of using it instead of fractions.Fraction. Honestly, for 7% more performance in an application benchmark, I'd consider ripping the GCD implementation in CPython out and copying it over. But that would involve a huge tail of code dependencies because it's tightly linked into longobject.c and the PyLong internals. It would be much easier if CPython simply exposed the function – as it did until a week ago, when 3.13a1 was released.

[scoder]

I created PR #111162