GeezerVison

Thanks for the updates @skirpichev, I enabled automerge.

@skirpichev: If you are interested, there are other macros which might be worth it to soft deprecate such as Py_MEMCPY(). I removed this macro in the limited C API version 3.11:

#if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 < 0x030b0000
#  define Py_MEMCPY memcpy
#endif

@vstinner, I think automerge wont work due to canceled test (I saw similar failure in #118000).

@vstinner, we can deprecate also Py_INFINITY, Py_NAN and Py_HUGE_VAL. For the last one, probably we could also update code to use INFINITY instead. What do you think?

What do you think?

You can start by avoiding these macros in Python code base and see how it goes.

Py_INFINITY and Py_NAN add a (double) cast.

Py_INFINITY and Py_NAN add a (double) cast.

Hmm, from C11 Sec 7.2: "The macro INFINITY expands to a constant expression of type float representing positive or unsigned infinity, if available [...] The macro NAN is defined if and only if the implementation supports quiet NaNs for the float type. It expands to a constant expression of type float representing a quiet NaN." (c)

As now build requirements include "Support for IEEE 754 floating point numbers and floating point Not-a-Number (NaN).", I think nowadays this type cast is useless.

Yet, anyway, replacing (with a soft deprecation) Py_HUGE_VAL by Py_INFINITY - probably does make sense. I was mentioned in #104202 (comment). One obvious pro: current using both Py_HUGE_VAL and Py_INFINITY may confuse readers.