NumPy 2.1.3 维护版本发布全解析类型提升、加权分位数与构建生态修复实录【免费下载链接】numpyThe fundamental package for scientific computing with Python.项目地址: https://gitcode.com/gh_mirrors/nu/numpy导读本篇文章基于 NumPy 仓库中的 2.1.3 版本更新日志系统梳理这一维护版本背后的 21 个合并 PR从用户自定义 dtype 在类型提升时的 can-cast 语义修复、加权分位数weighted quantile在零权重边界下的行为修正到npy_find_descr_for_scalar引用计数泄漏与 SWIG 4.3 兼容性调整。读者将从中了解 NumPy 2.1.x 分支的维护节奏、各修复对应的底层源码位置以及如何在源码树中验证这些变更。一、版本概况2.1.x 分支的第三次维护迭代NumPy 2.1.3 是 2.1.x 稳定分支的第三个补丁版本属于纯维护性发布——不引入新特性聚焦于缺陷修复、构建问题修复与依赖升级。根据更新日志本次发布共有15 位贡献者参与其中 6 位名字带 号者是首次为 NumPy 贡献补丁的新人合计合并了21 个 pull request。从 PR 标题的分布可以看出2.1.3 的维护工作覆盖四条主线类别代表 PR关注点核心 Bug 修复#27543、#27563、#27672、#27673dtype 类型提升、统计函数、引用计数、字符串 dtype构建系统#27562、#27566、#27568、#27571Meson、GCC-13、__STDC_VERSION__、tempita 内嵌兼容性适配#27593、#27669SWIG 4.3、wasm32 运行时CI / 依赖维护#27537、#27538、#27561、#27565、#27592、#27616actions/cache、cibuildwheel、Highway、QEMU 工作流下文将按主题深入剖析这些变更的技术内涵并结合仓库源码给出验证路径。二、类型提升与 dtype 相关修复核心语义2.1 用户自定义 dtype 与 Python 标量的 can-cast 修复#27543PR #27543BUG: Fix user dtype can-cast with python scalar during promotion这条修复直指类型提升promotion链路中的一个隐蔽缺陷当用户自定义 dtype 与 Python 标量参与运算时是否可以安全转换can-cast的判断结果可能出现偏差。要理解这条修复需要先认识本次发布中另一个同名函数——npy_find_descr_for_scalar。该函数定义在 numpy/_core/src/multiarray/abstractdtypes.c其职责是当用户传入 Python 字面量int、float、complex、str时根据运算目标 dtype 与标量自身 dtype 的公共 dtypecommon DType推导出实际应使用的 descriptor。注释中明确指出该函数服务于 special promotion rules——因为 Python 标量在参与运算时并不天然具备一个确定的 descriptor需要结合操作数共同决定。该函数的调用点散布在多个关键路径中包括numpy/_core/src/multiarray/convert_datatype.c类型转换前的 descriptor 推导numpy/_core/src/multiarray/multiarraymodule.c数组构造时的标量描述numpy/_core/src/umath/ufunc_object.cufunc 类型解析type resolution。因此任何涉及Python 标量 自定义 dtype的类型提升场景——例如自定义 dtype 数组与np.int64(3)相加——都在 #27543 的修复范围内。2.2 StringDType / unicode 提升器修复#27673PR #27673BUG: fixes for StringDType/unicode promotersStringDType 是 NumPy 2.x 引入的可变长度字符串 dtype对应 NEP 55字符串 dtype其提升器promoter负责处理 StringDType 与固定宽度字符串 dtype、Pythonstr标量之间的运算类型推导。本次修复针对提升器中字符串/unicode 路径的边界行为。从源码结构看StringDType 在类型系统中具有特殊地位numpy/_core/src/multiarray/array_coercion.c 中明确允许 StringDType 将 Pythonstr视为其标量类型numpy/_core/src/multiarray/convert_datatype.c 在公共 dtype 推导时对参数化parametricdtype 做了特殊处理而 StringDType 需要排除在外因为它携带独立的内部状态如分配器numpy/_core/src/multiarray/descriptor.c 指出带 finalize 槽位的 dtype如 StringDType按实例携带状态。这类提升器层面的修复通常影响的是np.result_type、np.promote_types以及 ufunc 对字符串输入的自动类型选择是 2.1.x 系列对 NEP 55 落地质量的持续打磨。三、加权分位数在零权重下的边界修复#27563PR #27563BUG: weighted quantile for some zero weights (#27549)这是 2.1.3 中最具用户可感知价值的一条统计功能修复背后是 issue #27549 报告的场景当权重数组在开头或结尾包含零权重时np.quantile/np.percentile在分位数取 0 或 1 时可能返回错误结果。3.1 底层实现加权分位数的算法路径加权分位数目前仅支持methodinverted_cdf一种方法其完整实现位于 numpy/lib/_function_base_impl.py。算法核心步骤为排序对数据沿目标轴排序np.argsort权重数组同步重排构造经验 CDF计算权重的累计和并归一化即cdf weights.cumsum(axis0) / cdf[-1]插值查找用np.searchsorted(cdf, quantiles, sideleft)找到满足sum(weights[j], j0..i-1) q sum(weights[j], j0..i)的索引。文档字符串 numpy/lib/_function_base_impl.py 给出了加权分位数的数学定义将经验 CDF 替换为加权版本P(Y t) (1 / Σwᵢ) · Σ wᵢ · 1{xᵢ t}并保证覆盖条件coverage conditions依然成立。3.2 零权重问题的根因与修复方式问题出在第 3 步权重必须非负但可以为 0。当序列开头存在零权重时CDF 前段会出现连续 0 值此时对quantile0执行searchsorted会选中第一个元素对应权重为 0 的数据而正确行为应选中第一个权重大于 0 的元素。修复方案非常精巧见 numpy/lib/_function_base_impl.py# Weights must be non-negative, so we might have zero weights at the # beginning leading to some leading zeros in cdf. The call to # np.searchsorted for quantiles0 will then pick the first element, # but should pick the first one larger than zero. We # therefore simply set 0 values in cdf to -1. if np.any(cdf[0, ...] 0): cdf[cdf 0] -1即将 CDF 中的所有 0 值替换为 -1使searchsorted对q0的查找跳过所有零权重前缀正确落在首个正权重元素上同时由于cdf已归一化最大值为 1q1时的越界索引也通过minimum(indices, values_count - 1)截断处理。3.3 测试验证仓库中的回归用例对应的回归测试位于 numpy/lib/tests/test_function_base.py测试用例test_quantile_weights_min_max精确复现了该边界场景pytest.mark.parametrize(method, methods_supporting_weights) def test_quantile_weights_min_max(self, method): # Test weighted quantile at 0 and 1 with leading and trailing zero # weights. w [0, 0, 1, 2, 3, 0] y np.arange(6) y_min np.quantile(y, 0, weightsw, methodinverted_cdf) y_max np.quantile(y, 1, weightsw, methodinverted_cdf) assert y_min y[2] # 2 assert y_max y[4] # 4数据y [0, 1, 2, 3, 4, 5]、权重w [0, 0, 1, 2, 3, 0]虽然索引 0、1 处有权重 0 的元素但quantile(..., 0)必须返回y[2] 2第一个正权重位置quantile(..., 1)必须返回y[4] 4最后一个正权重位置。这组断言正是 #27563 修复后需要持续保障的行为契约。同文件中还配套有负权重校验测试test_quantile_weights_raises_negative_weights要求抛出ValueError: Weights must be non-negative.对应实现见 numpy/lib/_function_base_impl.py以及非inverted_cdf方法使用权重时的报错测试共同构成加权分位数功能的完整测试矩阵。四、内存安全与引用计数修复4.1 npy_find_descr_for_scalar 的引用计数泄漏#27672PR #27672BUG: Fix a reference count leak in npy_find_descr_for_scalar回到 numpy/_core/src/multiarray/abstractdtypes.c 中npy_find_descr_for_scalar的实现可以清晰看到引用计数管理的关键分支PyArray_DTypeMeta *common PyArray_CommonDType(in_DT, op_DT); if (common NULL) { PyErr_Clear(); /* This is fine. We simply assume the original descr is viable. */ Py_INCREF(original_descr); return original_descr; } ... Py_DECREF(common); return res;函数在多个路径中执行Py_INCREF增加引用后返回 descriptor所有调用方如npy_update_operand_if_pyscalar都会在后续Py_DECREF释放。本次修复针对的是某个特定错误路径下Py_INCREF与Py_DECREF不平衡导致的引用计数泄漏——这类 bug 在长期运行的进程中会累积为内存泄漏通常由测试工具如 tracemalloc 或 pytest-leaks与代码审查发现修复后需要通过完整的引用计数回归测试验证。4.2 PyTraceMallocTrack 的错误处理#27569PR #27569BUG: handle possible error for PyTraceMallocTrack该修复为PyTraceMallocTrack相关的调用补充了错误处理路径。PyTraceMallocTrack是 CPython 的 tracemalloc 机制中用于跟踪内存分配的内部 APINumPy 在特定内存分配路径如 numpy/_core/src 下的内存管理代码中调用它。此前若该调用返回错误状态NumPy 可能忽略并继续执行导致调试信息缺失或潜在的资源状态不一致本次修复确保错误被正确捕获和传播。4.3 npy_atomic.h 的编译警告修复#27574PR #27574BUG: Fix warning differs in levels of indirection in npy_atomic.h原子操作头文件 是 NumPy 底层并发原语的实现所在。修复前在部分编译器与平台组合下会触发 differs in levels of indirection指针间接层级不一致警告——这类警告通常源于类型不匹配的指针传递虽然不直接导致运行错误但会污染构建输出且在开启-Werror的严格构建中会直接失败。修复后该头文件可被干净地编译。五、构建系统与跨平台兼容性修复5.1 构建系统基础设施升级2.1.3 对构建栈做了多处同步升级#27562将内嵌vendoredMeson 构建系统升级到1.5.2。NumPy 自 1.22 起逐步迁移到 Meson参见 building_with_meson.md内嵌版本用于无网络环境下的可重复构建#27571从 Cython 内嵌vendortempita模板引擎。tempita 被用于*.src模板文件的预渲染如_core/src下大量.src文件经 numpy/_build_utils/tempita.py 处理后生成 C 源码内嵌后消除了对外部运行时依赖的脆弱性#27592将 SIMD 库Highway更新到最新版本。Highway 是 Google 的跨平台 SIMD 抽象库NumPy 在 numpy/_core/src/umath/loops_arithmetic_timedelta.dispatch.cpp、loops_hyperbolic.dispatch.cpp.src、loops_logical.dispatch.cpp 等 dispatch 文件中通过hwy/highway.h调用其 API 实现指令集分派#27568构建时不再将__STDC_VERSION__置为 0。此前构建脚本在某些配置下会错误地清空该标准版本宏导致依赖 C 标准版本的代码路径如_Generic、可变参数宏行为异常。5.2 编译器兼容性#27566满足GCC-13的-Wpendantic严格检查要求。GCC-13 对 C 代码的严格模式检查更严格本次修复调整了若干违反约束的写法#27539MSVC不支持#warning预处理指令相关代码路径改为条件编译避免 Windows 上 MSVC 编译报错。5.3 平台支持扩展#27570开始为Windows 构建 free-threaded无 GILwheel。这是 NumPy 对 PEP 703自由线程 Python支持计划的一部分仓库中已有配套的自由线程相关测试如 numpy/_core/tests/test_limited_api.py 等涉及Py_GIL_DISABLED的测试文件#27669修复wasm32平台下numpy._core的运行时类型错误改善 WebAssembly/Emscripten 环境的可用性对应工具链配置见 tools/ci/emscripten。5.4 SWIG 4.3 兼容性#27593PR #27593BUG: Adjust numpy.i for SWIG 4.3 compatibilitynumpy.i 是 NumPy 官方维护的 SWIG typemap 集合用于在 C/C 扩展与 Python 数组之间自动转换参数。SWIG 4.3 引入了新的代码生成行为导致旧 typemap 产生不兼容的胶水代码本次修复对其进行了适配。该文件的测试框架见 tools/swig/README 与 tools/swig/test 目录包含 Vector.i、Matrix.i 等多组测试接口文件。六、CI 工作流与依赖维护2.1.3 同时完成了一批工程化维护保证 2.1.x 分支的持续集成稳定性#27537actions/cache从 4.0.2 升级到 4.1.1优化 CI 缓存行为#27538pypa/cibuildwheel从 2.21.2 升级到 2.21.3同步 wheel 构建工具链#27561environment.yml 中的 Python 版本提升到3.12使开发环境与主流 CI 保持一致#27565macOS conda 测试改用miniforge作为 conda 发行版避免 Anaconda 默认渠道带来的授权与网络问题#27616修复 Linux 下QEMUCI 工作流用于交叉架构仿真测试的故障#27512MAINT 性质的后备改动为 2.1.x 分支的后续开发做准备。七、贡献者名单与社区信息本次发布共有 15 位贡献者带 号者为首次贡献首次贡献者Abhishek Kumar、Austin、Benjamin A. Beasley、Marcel Telka、Michael Davidsaver、kp2pml30常规贡献者Charles Harris、Christian Lorentzen、Matti Picus、Nathan Goldbaum、Peter Hawkins、Raghuveer Devulapalli、Ralf Gommers、Sebastian Berg以及自动化机器人dependabot[bot]其中 Charles Harris、Matti Picus、Ralf Gommers、Sebastian Berg 是 NumPy 长期核心维护者dependabot 则负责依赖升级类 PR 的自动提交。完整名单见 2.1.3 更新日志。八、如何在源码树中验证 2.1.3 的修复对于希望深入验证上述修复的读者推荐按以下路径在仓库中交叉检索加权分位数实现位于 numpy/lib/_function_base_impl.pyquantile/percentile入口与_quantile_ureduce_func加权分支回归测试位于 numpy/lib/tests/test_function_base.py。可将w [0, 0, 1, 2, 3, 0]场景直接复制到本地 Python 环境运行np.quantile(np.arange(6), [0, 1], weightsw, methodinverted_cdf)验证类型提升链路从 numpy/_core/src/multiarray/abstractdtypes.c 的npy_find_descr_for_scalar出发沿调用点convert_datatype.c、ufunc_object.c追踪 Python 标量的 descriptor 推导全流程构建系统检查 pyproject.toml 与 meson.options 中的 Meson 配置确认内嵌版本与构建选项SWIG 集成阅读 tools/swig/numpy.i 顶部关于SWIG_FILE_WITH_INIT与 typemap 的说明结合 tools/swig/test 下的测试接口理解参数转换契约。需要说明的是2.1.3 作为维护版本不含新功能其全部变更均已包含在后续的 2.2.x 与 2.3.x 版本中对于使用 2.1.x 的用户升级到 2.1.3 即可获得上述所有修复无需承担任何 API 变更风险。结语NumPy 2.1.3 是典型的小而精维护版本没有头条功能却在类型提升语义、加权统计边界、内存引用管理和跨平台构建这四个维度上修复了 21 个实际问题。其中加权分位数的零权重修复#27563对数据科学用户具有直接的实践价值——它保证了weights含 0 时quantile(..., 0)与quantile(..., 1)的结果严格落在正权重样本上而npy_find_descr_for_scalar的引用计数修复#27672与 StringDType 提升器修复#27673则从底层保障了自定义 dtype 生态的健壮性。对于维护者而言更新日志 本身就是一份极佳的最小修复集合案例展示了 NumPy 如何在稳定分支中平衡功能冻结与缺陷修复的节奏。【免费下载链接】numpyThe fundamental package for scientific computing with Python.项目地址: https://gitcode.com/gh_mirrors/nu/numpy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 NumPy 2.1.3 维护版本发布全解析：类型提升、加权分位数与构建生态修复实录
NumPy 2.1.3 维护版本发布全解析类型提升、加权分位数与构建生态修复实录【免费下载链接】numpyThe fundamental package for scientific computing with Python.项目地址: https://gitcode.com/gh_mirrors/nu/numpy导读本篇文章基于 NumPy 仓库中的 2.1.3 版本更新日志系统梳理这一维护版本背后的 21 个合并 PR从用户自定义 dtype 在类型提升时的 can-cast 语义修复、加权分位数weighted quantile在零权重边界下的行为修正到npy_find_descr_for_scalar引用计数泄漏与 SWIG 4.3 兼容性调整。读者将从中了解 NumPy 2.1.x 分支的维护节奏、各修复对应的底层源码位置以及如何在源码树中验证这些变更。一、版本概况2.1.x 分支的第三次维护迭代NumPy 2.1.3 是 2.1.x 稳定分支的第三个补丁版本属于纯维护性发布——不引入新特性聚焦于缺陷修复、构建问题修复与依赖升级。根据更新日志本次发布共有15 位贡献者参与其中 6 位名字带 号者是首次为 NumPy 贡献补丁的新人合计合并了21 个 pull request。从 PR 标题的分布可以看出2.1.3 的维护工作覆盖四条主线类别代表 PR关注点核心 Bug 修复#27543、#27563、#27672、#27673dtype 类型提升、统计函数、引用计数、字符串 dtype构建系统#27562、#27566、#27568、#27571Meson、GCC-13、__STDC_VERSION__、tempita 内嵌兼容性适配#27593、#27669SWIG 4.3、wasm32 运行时CI / 依赖维护#27537、#27538、#27561、#27565、#27592、#27616actions/cache、cibuildwheel、Highway、QEMU 工作流下文将按主题深入剖析这些变更的技术内涵并结合仓库源码给出验证路径。二、类型提升与 dtype 相关修复核心语义2.1 用户自定义 dtype 与 Python 标量的 can-cast 修复#27543PR #27543BUG: Fix user dtype can-cast with python scalar during promotion这条修复直指类型提升promotion链路中的一个隐蔽缺陷当用户自定义 dtype 与 Python 标量参与运算时是否可以安全转换can-cast的判断结果可能出现偏差。要理解这条修复需要先认识本次发布中另一个同名函数——npy_find_descr_for_scalar。该函数定义在 numpy/_core/src/multiarray/abstractdtypes.c其职责是当用户传入 Python 字面量int、float、complex、str时根据运算目标 dtype 与标量自身 dtype 的公共 dtypecommon DType推导出实际应使用的 descriptor。注释中明确指出该函数服务于 special promotion rules——因为 Python 标量在参与运算时并不天然具备一个确定的 descriptor需要结合操作数共同决定。该函数的调用点散布在多个关键路径中包括numpy/_core/src/multiarray/convert_datatype.c类型转换前的 descriptor 推导numpy/_core/src/multiarray/multiarraymodule.c数组构造时的标量描述numpy/_core/src/umath/ufunc_object.cufunc 类型解析type resolution。因此任何涉及Python 标量 自定义 dtype的类型提升场景——例如自定义 dtype 数组与np.int64(3)相加——都在 #27543 的修复范围内。2.2 StringDType / unicode 提升器修复#27673PR #27673BUG: fixes for StringDType/unicode promotersStringDType 是 NumPy 2.x 引入的可变长度字符串 dtype对应 NEP 55字符串 dtype其提升器promoter负责处理 StringDType 与固定宽度字符串 dtype、Pythonstr标量之间的运算类型推导。本次修复针对提升器中字符串/unicode 路径的边界行为。从源码结构看StringDType 在类型系统中具有特殊地位numpy/_core/src/multiarray/array_coercion.c 中明确允许 StringDType 将 Pythonstr视为其标量类型numpy/_core/src/multiarray/convert_datatype.c 在公共 dtype 推导时对参数化parametricdtype 做了特殊处理而 StringDType 需要排除在外因为它携带独立的内部状态如分配器numpy/_core/src/multiarray/descriptor.c 指出带 finalize 槽位的 dtype如 StringDType按实例携带状态。这类提升器层面的修复通常影响的是np.result_type、np.promote_types以及 ufunc 对字符串输入的自动类型选择是 2.1.x 系列对 NEP 55 落地质量的持续打磨。三、加权分位数在零权重下的边界修复#27563PR #27563BUG: weighted quantile for some zero weights (#27549)这是 2.1.3 中最具用户可感知价值的一条统计功能修复背后是 issue #27549 报告的场景当权重数组在开头或结尾包含零权重时np.quantile/np.percentile在分位数取 0 或 1 时可能返回错误结果。3.1 底层实现加权分位数的算法路径加权分位数目前仅支持methodinverted_cdf一种方法其完整实现位于 numpy/lib/_function_base_impl.py。算法核心步骤为排序对数据沿目标轴排序np.argsort权重数组同步重排构造经验 CDF计算权重的累计和并归一化即cdf weights.cumsum(axis0) / cdf[-1]插值查找用np.searchsorted(cdf, quantiles, sideleft)找到满足sum(weights[j], j0..i-1) q sum(weights[j], j0..i)的索引。文档字符串 numpy/lib/_function_base_impl.py 给出了加权分位数的数学定义将经验 CDF 替换为加权版本P(Y t) (1 / Σwᵢ) · Σ wᵢ · 1{xᵢ t}并保证覆盖条件coverage conditions依然成立。3.2 零权重问题的根因与修复方式问题出在第 3 步权重必须非负但可以为 0。当序列开头存在零权重时CDF 前段会出现连续 0 值此时对quantile0执行searchsorted会选中第一个元素对应权重为 0 的数据而正确行为应选中第一个权重大于 0 的元素。修复方案非常精巧见 numpy/lib/_function_base_impl.py# Weights must be non-negative, so we might have zero weights at the # beginning leading to some leading zeros in cdf. The call to # np.searchsorted for quantiles0 will then pick the first element, # but should pick the first one larger than zero. We # therefore simply set 0 values in cdf to -1. if np.any(cdf[0, ...] 0): cdf[cdf 0] -1即将 CDF 中的所有 0 值替换为 -1使searchsorted对q0的查找跳过所有零权重前缀正确落在首个正权重元素上同时由于cdf已归一化最大值为 1q1时的越界索引也通过minimum(indices, values_count - 1)截断处理。3.3 测试验证仓库中的回归用例对应的回归测试位于 numpy/lib/tests/test_function_base.py测试用例test_quantile_weights_min_max精确复现了该边界场景pytest.mark.parametrize(method, methods_supporting_weights) def test_quantile_weights_min_max(self, method): # Test weighted quantile at 0 and 1 with leading and trailing zero # weights. w [0, 0, 1, 2, 3, 0] y np.arange(6) y_min np.quantile(y, 0, weightsw, methodinverted_cdf) y_max np.quantile(y, 1, weightsw, methodinverted_cdf) assert y_min y[2] # 2 assert y_max y[4] # 4数据y [0, 1, 2, 3, 4, 5]、权重w [0, 0, 1, 2, 3, 0]虽然索引 0、1 处有权重 0 的元素但quantile(..., 0)必须返回y[2] 2第一个正权重位置quantile(..., 1)必须返回y[4] 4最后一个正权重位置。这组断言正是 #27563 修复后需要持续保障的行为契约。同文件中还配套有负权重校验测试test_quantile_weights_raises_negative_weights要求抛出ValueError: Weights must be non-negative.对应实现见 numpy/lib/_function_base_impl.py以及非inverted_cdf方法使用权重时的报错测试共同构成加权分位数功能的完整测试矩阵。四、内存安全与引用计数修复4.1 npy_find_descr_for_scalar 的引用计数泄漏#27672PR #27672BUG: Fix a reference count leak in npy_find_descr_for_scalar回到 numpy/_core/src/multiarray/abstractdtypes.c 中npy_find_descr_for_scalar的实现可以清晰看到引用计数管理的关键分支PyArray_DTypeMeta *common PyArray_CommonDType(in_DT, op_DT); if (common NULL) { PyErr_Clear(); /* This is fine. We simply assume the original descr is viable. */ Py_INCREF(original_descr); return original_descr; } ... Py_DECREF(common); return res;函数在多个路径中执行Py_INCREF增加引用后返回 descriptor所有调用方如npy_update_operand_if_pyscalar都会在后续Py_DECREF释放。本次修复针对的是某个特定错误路径下Py_INCREF与Py_DECREF不平衡导致的引用计数泄漏——这类 bug 在长期运行的进程中会累积为内存泄漏通常由测试工具如 tracemalloc 或 pytest-leaks与代码审查发现修复后需要通过完整的引用计数回归测试验证。4.2 PyTraceMallocTrack 的错误处理#27569PR #27569BUG: handle possible error for PyTraceMallocTrack该修复为PyTraceMallocTrack相关的调用补充了错误处理路径。PyTraceMallocTrack是 CPython 的 tracemalloc 机制中用于跟踪内存分配的内部 APINumPy 在特定内存分配路径如 numpy/_core/src 下的内存管理代码中调用它。此前若该调用返回错误状态NumPy 可能忽略并继续执行导致调试信息缺失或潜在的资源状态不一致本次修复确保错误被正确捕获和传播。4.3 npy_atomic.h 的编译警告修复#27574PR #27574BUG: Fix warning differs in levels of indirection in npy_atomic.h原子操作头文件 是 NumPy 底层并发原语的实现所在。修复前在部分编译器与平台组合下会触发 differs in levels of indirection指针间接层级不一致警告——这类警告通常源于类型不匹配的指针传递虽然不直接导致运行错误但会污染构建输出且在开启-Werror的严格构建中会直接失败。修复后该头文件可被干净地编译。五、构建系统与跨平台兼容性修复5.1 构建系统基础设施升级2.1.3 对构建栈做了多处同步升级#27562将内嵌vendoredMeson 构建系统升级到1.5.2。NumPy 自 1.22 起逐步迁移到 Meson参见 building_with_meson.md内嵌版本用于无网络环境下的可重复构建#27571从 Cython 内嵌vendortempita模板引擎。tempita 被用于*.src模板文件的预渲染如_core/src下大量.src文件经 numpy/_build_utils/tempita.py 处理后生成 C 源码内嵌后消除了对外部运行时依赖的脆弱性#27592将 SIMD 库Highway更新到最新版本。Highway 是 Google 的跨平台 SIMD 抽象库NumPy 在 numpy/_core/src/umath/loops_arithmetic_timedelta.dispatch.cpp、loops_hyperbolic.dispatch.cpp.src、loops_logical.dispatch.cpp 等 dispatch 文件中通过hwy/highway.h调用其 API 实现指令集分派#27568构建时不再将__STDC_VERSION__置为 0。此前构建脚本在某些配置下会错误地清空该标准版本宏导致依赖 C 标准版本的代码路径如_Generic、可变参数宏行为异常。5.2 编译器兼容性#27566满足GCC-13的-Wpendantic严格检查要求。GCC-13 对 C 代码的严格模式检查更严格本次修复调整了若干违反约束的写法#27539MSVC不支持#warning预处理指令相关代码路径改为条件编译避免 Windows 上 MSVC 编译报错。5.3 平台支持扩展#27570开始为Windows 构建 free-threaded无 GILwheel。这是 NumPy 对 PEP 703自由线程 Python支持计划的一部分仓库中已有配套的自由线程相关测试如 numpy/_core/tests/test_limited_api.py 等涉及Py_GIL_DISABLED的测试文件#27669修复wasm32平台下numpy._core的运行时类型错误改善 WebAssembly/Emscripten 环境的可用性对应工具链配置见 tools/ci/emscripten。5.4 SWIG 4.3 兼容性#27593PR #27593BUG: Adjust numpy.i for SWIG 4.3 compatibilitynumpy.i 是 NumPy 官方维护的 SWIG typemap 集合用于在 C/C 扩展与 Python 数组之间自动转换参数。SWIG 4.3 引入了新的代码生成行为导致旧 typemap 产生不兼容的胶水代码本次修复对其进行了适配。该文件的测试框架见 tools/swig/README 与 tools/swig/test 目录包含 Vector.i、Matrix.i 等多组测试接口文件。六、CI 工作流与依赖维护2.1.3 同时完成了一批工程化维护保证 2.1.x 分支的持续集成稳定性#27537actions/cache从 4.0.2 升级到 4.1.1优化 CI 缓存行为#27538pypa/cibuildwheel从 2.21.2 升级到 2.21.3同步 wheel 构建工具链#27561environment.yml 中的 Python 版本提升到3.12使开发环境与主流 CI 保持一致#27565macOS conda 测试改用miniforge作为 conda 发行版避免 Anaconda 默认渠道带来的授权与网络问题#27616修复 Linux 下QEMUCI 工作流用于交叉架构仿真测试的故障#27512MAINT 性质的后备改动为 2.1.x 分支的后续开发做准备。七、贡献者名单与社区信息本次发布共有 15 位贡献者带 号者为首次贡献首次贡献者Abhishek Kumar、Austin、Benjamin A. Beasley、Marcel Telka、Michael Davidsaver、kp2pml30常规贡献者Charles Harris、Christian Lorentzen、Matti Picus、Nathan Goldbaum、Peter Hawkins、Raghuveer Devulapalli、Ralf Gommers、Sebastian Berg以及自动化机器人dependabot[bot]其中 Charles Harris、Matti Picus、Ralf Gommers、Sebastian Berg 是 NumPy 长期核心维护者dependabot 则负责依赖升级类 PR 的自动提交。完整名单见 2.1.3 更新日志。八、如何在源码树中验证 2.1.3 的修复对于希望深入验证上述修复的读者推荐按以下路径在仓库中交叉检索加权分位数实现位于 numpy/lib/_function_base_impl.pyquantile/percentile入口与_quantile_ureduce_func加权分支回归测试位于 numpy/lib/tests/test_function_base.py。可将w [0, 0, 1, 2, 3, 0]场景直接复制到本地 Python 环境运行np.quantile(np.arange(6), [0, 1], weightsw, methodinverted_cdf)验证类型提升链路从 numpy/_core/src/multiarray/abstractdtypes.c 的npy_find_descr_for_scalar出发沿调用点convert_datatype.c、ufunc_object.c追踪 Python 标量的 descriptor 推导全流程构建系统检查 pyproject.toml 与 meson.options 中的 Meson 配置确认内嵌版本与构建选项SWIG 集成阅读 tools/swig/numpy.i 顶部关于SWIG_FILE_WITH_INIT与 typemap 的说明结合 tools/swig/test 下的测试接口理解参数转换契约。需要说明的是2.1.3 作为维护版本不含新功能其全部变更均已包含在后续的 2.2.x 与 2.3.x 版本中对于使用 2.1.x 的用户升级到 2.1.3 即可获得上述所有修复无需承担任何 API 变更风险。结语NumPy 2.1.3 是典型的小而精维护版本没有头条功能却在类型提升语义、加权统计边界、内存引用管理和跨平台构建这四个维度上修复了 21 个实际问题。其中加权分位数的零权重修复#27563对数据科学用户具有直接的实践价值——它保证了weights含 0 时quantile(..., 0)与quantile(..., 1)的结果严格落在正权重样本上而npy_find_descr_for_scalar的引用计数修复#27672与 StringDType 提升器修复#27673则从底层保障了自定义 dtype 生态的健壮性。对于维护者而言更新日志 本身就是一份极佳的最小修复集合案例展示了 NumPy 如何在稳定分支中平衡功能冻结与缺陷修复的节奏。【免费下载链接】numpyThe fundamental package for scientific computing with Python.项目地址: https://gitcode.com/gh_mirrors/nu/numpy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考