Not sure that this is the best solution, but it is the simplest.

🤖 New build scheduled with the buildbot fleet by @skirpichev for commit 08cc039 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F156887%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

This PR has the side effect that the public C API function _Py_c_pow() now sets errno = 0; on success (except if either the base or the exponent is zero, in which case, on success, errno is left unchanged). The old code, on success, when neither argument was zero, did set errno to zero if it was previously ERANGE, but if it was, e.g., ENOENT, then it left it unchanged. Well, except if the real or imaginary part of either the base or the exponent was not finite, in which case, on success, ERANGE was also left unchanged.

The Linux man page for errno says, "The value of errno is never set to zero by any system call or library function."
Of course, Python does not have to abide by this restriction, but then it might be good to update the documentation for _Py_c_pow() to mention that errno may or may not be set to zero on success. See also: #156914

When I merged main into #156968 this change (setting errno to zero) was removed, so merging that PR is another option available to you. 😉

This PR has the side effect that the public C API function _Py_c_pow() now sets errno = 0; on success
The Linux man page for errno says, "The value of errno is never set to zero by any system call or library function."

I don't think this poses practical problems: we shouldn't match libc behavior, it also still correct wrt docs (they say errno is set on overflows, everything else is unspecified). Correct workflow is (as before):

errno = 0;
result = _Py_c_pow(base, exp);
if (errno == ERANGE) {
    ...

Though, I would prefer same errno handling as for libc function, i.e. restore saved errno on success. I can reopen issue or include a fix to #155527.