BUG: error: implicit declaration of function ‘_Py_HashDouble’ (building with Python 3.13~alpha1)

[befeleme]

Describe the issue:

Hello,
in Fedora Linux, we've already started integrating Python 3.13 into the ecosystem.
Numpy is high on our list of priorities as many other libraries depend on it.
During the RPM build I've encountered a build failure that I'm unable to mitigate, see below.

Error message:

In file included from ../../numpy/core/src/multiarray/scalartypes.c.src:16:
  ../../numpy/core/src/multiarray/scalartypes.c.src: In function ‘float_arrtype_hash’:
  ../../numpy/core/src/common/npy_pycompat.h:12:24: error: implicit declaration of function ‘_Py_HashDouble’; did you mean ‘Npy_HashDouble’? [-Werror=implicit-function-declaration]
     12 | #define Npy_HashDouble _Py_HashDouble
        |                        ^~~~~~~~~~~~~~
  ../../numpy/core/src/multiarray/scalartypes.c.src:3418:12: note: in expansion of macro ‘Npy_HashDouble’
   3418 |     return Npy_HashDouble(obj, (double)PyArrayScalar_VAL(obj, @name@));
        |            ^~~~~~~~~~~~~~

Runtime information:

1.26.0

Context for the issue:

This function has been moved to the internal API: python/cpython#107026
There's already a discussion about restoring it: python/cpython#111418

At this point, we're unable to build a working numpy RPM and our integration efforts have to pause.

[ngoldbaum]

That python pull request isn't about restoring the function we're using though, just the macros used to implement it. I'll comment on the upstream issue to ask if it makes sense to make the function public.

That said, looking over the implementation, I'm sure we could just vendor it too if these macros are public.

[seberg]

Thanks for posting there. Python restoring this would be best I think, otherwise we will basically have to either copy it and assume Python won't change it anyway or convert our float32, etc. to a Python float just to get the hash (and even then we need to hardcode the NaN path).

[rgommers]

I'd avoid doing any work here - CPython may indeed restore them. A lot of folks are quite unhappy with the level of breakage, and some of it may be reverted or new public C API added to cover the use case for some private function. Cython won't work for the foreseeable future anyway, so best to wait to see what will happen there.

[hroncok]

Cython won't work for the foreseeable future anyway...

Not quite true. cython/cython#5767 was merged and was released as 3.0.5.

[rgommers]

Ah great, thanks @hroncok. I was going off of https://discuss.python.org/t/is-python-3-13-going-to-be-python-4/37490, where Stefan wrote only yesterday "The amount of breakage is so huge that I’m personally giving up on fixing it." So I didn't expect that quick release - seems like the last word hasn't been said about this though.

[seberg]

Going to close this, Python will make this public or revert soon enough, until then there is nothing to do.

And when that happens a PR to remove the underscore on newer versions would be appreciated, but we might have ust forgotton about this anyway.

(I don't disgree with Victor's sentiment on the CPython issue that it is very early to start expecting things to run without hiccups on 3.13.)

[ngoldbaum]

FWIW: python/cpython#112095