为什么Python NumPy 2.0移除了某些旧的别名API？-Python教程-PHP中文网

NumPy 2.0 移除 np.float_ 等别名是因类型系统重构需要：它们模糊易歧义、违反PEP 698、无法用于类型提示、C API中已无对应实现；ndarray 不再支持直接类型注解，须改用 NDArray[np.float64]。

为什么python numpy 2.0移除了某些旧的别名api？

NumPy 2.0 移除 np.float_、np.int、np.complex_ 等别名，不是为了制造麻烦，而是类型系统重构的必然结果——这些别名长期模糊、易歧义，且与 Python 原生类型和类型提示标准（PEP 698）冲突。

为什么 `np.float_` 这类别名必须被删？

它们不是“功能错误”，而是设计债务：

np.float_ 实际恒等于 np.float64，但名字里没体现精度，误导用户以为它是“通用浮点”；同理 np.int 在不同平台可能映射到 int32 或 int64，破坏可移植性
Python 3.12+ 强推结构化类型提示，要求 dtype 注解必须可静态推导；而 np.float_ 这类别名无法被 mypy/pyright 当作泛型参数处理（比如 NDArray[np.float_] 直接报错）
NumPy C API 重写时，这些别名在底层已无对应实现；保留它们只会让 C 扩展维护更脆弱

`np.ndarray` 不能直接用在类型注解里了？

是的，这不是 bug，是分层设计：运行时对象和类型检查工具使用的类型系统被拆开了。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

np.ndarray 仍是合法的运行时类，x = np.array([1]) 完全不受影响
但类型注解 def f(x: np.ndarray) -> np.ndarray: 会失败——因为 np.ndarray 不再是 typing.Generic 的子类，也不支持方括号语法（如 np.ndarray[float]）
必须改用 from numpy.typing import NDArray，然后写成 NDArray[np.float64] 或更抽象的 NDArray[np.floating]

C 扩展编译失败，常见错误是 `undefined symbol: PyArray_GetBuffer`

这不是你代码写错了，是 NumPy 2.0 彻底砍掉了旧缓冲区协议路径。

旧扩展若直接调用 PyArray_GetBuffer、PyArray_ResolveBuffer，链接期就报错
新推荐路径是组合使用 PyArray_GetArrayParamsFromObject + PyArray_FromAny，语义更清晰、内存模型更安全
如果你维护 C 扩展，别试图“绕过”——必须重写缓冲区访问逻辑，否则 ABI 不兼容会导致运行时崩溃，而非简单报错

最常被忽略的一点：类型检查器（如 pyright）是否启用 numpy.typing 并不取决于你有没有写类型注解，而取决于你有没有显式导入 NDArray。哪怕只有一处用了 NDArray[np.float64]，整个项目的类型检查行为就会切换到 NumPy 2.0 模式——此时所有未迁移的旧注解都会立刻暴露。