AttributeError: module 'numpy' has no attribute 'float' after upgrading to NumPy 2.0

Replacing dtype=np.float in NumPy 2.0

NumPy 2.0 removed the scalar type aliases np.float, np.int, np.bool, np.complex, np.object, and np.str that had been deprecated since 1.20. In a large mixed Python/Cython codebase, these appearances fall into three contexts: dtype specifications in array-creation calls, type annotations, and Cython cdef declarations. Each requires a slightly different replacement strategy to avoid subtle precision or compatibility regressions.

Pattern for dtype=np.float

1. Replace dtype=np.float with dtype=np.float64 to preserve the original 64-bit IEEE 754 double semantics. Use this when the array's precision matters for downstream calculations or when the codebase previously relied on the alias's guaranteed width.
2. If the original intent was to accept any Python float or the dtype is later overridden, substitute the built-in float. Note that on most platforms float is also 64-bit, but the type is not tied to NumPy's internal layout. After replacement, inspect arr.dtype to confirm the expected itemsize (8 bytes).
3. Run a short test script that creates an array with the new dtype, checks arr.itemsize, and compares values against a reference created with the original np.float (if available) using numpy.testing.assert_array_equal or np.allclose. This step catches silent casting differences introduced by downstream libraries or mixed-precision code paths.

Cython cdef np.float_t declarations

In NumPy 2.0, the C-level typedef np.float_t maps to C double. A Cython declaration such as

cdef np.float_t x

should be updated to

cdef double x

if the 64-bit width is intended. If the original code used np.float to denote a platform-dependent float width (historically always 64-bit in NumPy, but conceptually wider on some architectures), verify the target platform's sizeof(double). Recompile the Cython extension against NumPy 2.0 headers; do not rely on source-level substitution alone, because the compiled .so or .pyd still embeds the old typedef layout.

numpy.compat shim layer

The numpy.compat module provides compatibility checks and deprecation warnings but does not ship a shim that re‑installs the removed scalar aliases. Incremental migration therefore requires automated source-level replacement followed by manual verification, rather than a drop‑in compatibility layer.

If your codebase contains Cython modules compiled against NumPy 1.x headers that are still loaded at runtime, confirm whether those extensions have been rebuilt for NumPy 2.0. Runtime mixing of 1.x and 2.0 type layouts can produce type‑mismatch errors that a simple find‑and‑replace won't resolve. Rebuilding those modules against the 2.0 headers is the recommended next step.