科学计算数据分析【免费下载链接】numpyThe fundamental package for scientific computing with Python.项目地址https://gitcode.com/gh_mirrors/nu/numpy点击查看免费下载本文围绕 NumPy 1.14.3 这一 bugfix 版本逐一拆解其三个核心修复点np.lib.recfunctions.fromrecords对 list-of-lists 输入的临时兼容、Python 2 下浮点类型输出到文件时的新式打印行为以及 legacy 打印模式下style参数对 0 维数组的修复并结合当前仓库源码说明这些修复背后的实现原理与影响范围。版本背景与定位NumPy 1.14.3 是紧随 1.14.2 之后发布的一个bugfix release缺陷修复版本其定位在 1.14.3-notes.rst 中说明得非常明确仅针对 1.14.2 发布后报告的少量 bug 进行修复不引入新特性。该版本支持Python 2.7 与 3.4 - 3.6。其中从 PIP 获取的 Python 3.6 wheels 基于 Python 3.6.2 构建向后兼容所有更早的 Python 3.6 版本源码发布包使用Cython 0.28.2完成 cythonize。从当前仓库看这条发布说明位于 doc/source/release/ 目录下与 1.12.0 到 2.5.3 的全部版本说明并列是研究 NumPy 历史行为变迁的第一手资料。值得留意的是1.14.x 系列处于记录数组recarray打印/构造机制和Python 2 打印风格两个过渡期的交汇点上因此本次修复的三条内容具有很强的承前启后色彩。三条核心修复逐项解析修复一np.lib.recfunctions.fromrecords接受 list-of-lists兼容至 1.15现象与修复1.14.2 之后np.lib.recfunctions.fromrecords记录数组工厂函数在收到列表的列表list-of-lists输入时出现回归1.14.3 将其恢复为可接受同时给出直至 1.15 仍兼容、之后将告警/报错的过渡预期。源码佐证在当前仓库中fromrecords的实现位于 numpy/_core/records.py#L665-L750其行为与发布说明高度吻合try: retval sb.array(recList, dtypedescr) except (TypeError, ValueError): # NumPy 1.19.0, 2020-01-01 shape _deprecate_shape_0_as_None(shape) ... _array recarray(shape, descr) for k in range(_array.size): _array[k] tuple(recList[k]) # list of lists instead of list of tuples ? # 2018-02-07, 1.14.1 warnings.warn( fromrecords expected a list of tuples, may have received a list of lists instead. In the future that will raise an error, FutureWarning, stacklevel2) return _array可以看到当recList无法直接按目标descr构造数组时TypeError/ValueError代码会回退为逐行转 tuple的慢路径并发出FutureWarning注释中的时间戳2018-02-07, 1.14.1与 1.14.3 发布说明2018 年 3 月前后时间线一致印证了该兼容分支正是 1.14.x 系列为缓解此问题而引入的源码 docstring 明确提示Use list of tuples rather than list of lists for faster processing即推荐输入格式始终是元组的列表list-of-lists 只是被容忍的兼容输入。同时numpy.ma.mrecords.fromrecords掩码记录数组版本位于 numpy/ma/mrecords.py#L514-L576在Notes中也写着同样建议Lists of tuples should be preferred over lists of lists for faster processing且其实现内部直接转调np.rec.fromrecords后.view(mrecarray)因此这一兼容行为同样作用于掩码记录数组。而np.lib.recfunctions中的fromrecords见 numpy/lib/recfunctions.py本质上也围绕np.rec.fromrecords展开读者可放心遵循同一输入规范。实操建议编写依赖np.rec.fromrecords/np.lib.recfunctions.fromrecords的代码时应一律使用list of tuples如[(456, dbe, 1.2), (2, de, 1.3)]作为输入避免触发慢路径与告警不要依赖 list-of-lists 的兼容行为——它在后续版本中已被收紧先告警、后报错属于临时的向后兼容窗口如需自动推断字段类型让formats与dtype均为None即可此时会先以 object 数组收集数据再逐列推断见 numpy/_core/records.py#L708-L714。修复二Python 2 下浮点类型使用新式打印风格写入文件现象与修复在 Python 2 环境中float类型对象在打印到文件而非终端时此前仍沿用 Python 2 的repr旧式风格如尾随的L、不同的精度取舍与 Python 3 行为不一致。1.14.3 通过为浮点类型覆盖tp_print槽位使print到文件时也统一走新式打印风格。源码佐证发布说明中对应的合并 PR 为#10862BUG: floating types should override tp_print (1.14 backport)。从当前仓库的结构看NumPy 标量类型的打印格式化集中在 numpy/_core/arrayprint.py格式化入口array2string位于 numpy/_core/arrayprint.py#L644-L648而tp_print槽位属于 C 层类型对象的打印协议——1.14 时代该实现位于 C 扩展multiarray中此处我们可通过行为层面理解该修复保证 Python 2 下print语句/函数无论输出目标是控制台还是重定向文件浮点数的字符串表示都采用与 Python 3 相同的新式规则从而消除跨版本输出差异。实际影响该修复对同一套代码在 Python 2/3 双版本下运行并生成文本输出日志、结果文件的场景意义重大。修复后Python 2.7 下写入文件的浮点输出与 Python 3.4-3.6 一致便于做跨版本结果的 diff 与回归比对。修复三legacy 打印模式下style参数对 0 维数组生效现象与修复在legacy1.13打印模式下向array2string/打印路径传入style参数时0 维数组标量数组未能正确应用该样式。1.14.3 修复后style在 legacy 模式 0 维数组的组合下也能正常工作。源码佐证array2string的legacy参数语义在当前仓库文档中有完整定义numpy/_core/arrayprint.py#L745-L750If set to the string1.13enables 1.13 legacy printing mode. This approximates numpy 1.13 print output by including a space in the sign position of floats anddifferent behavior for 0d arrays.也就是说legacy 模式本身就刻意改变了 0 维数组的打印行为——这正是该 bug 集中在 0d 数组上的原因。修复对应的 PR 为#10947BUG: style arg to array2string broken in legacy mode。在内部实现中_array2stringnumpy/_core/arrayprint.py#L606-L631会对 0 维数组做特殊处理if a.shape (): a data随后经由_formatArray应用separator、legacy等选项style在此链路中作为样式化前缀/后缀的一部分参与对齐计算legacy 模式下此前未正确传导本次修复即打通了该路径。实操建议在需要精确复现 NumPy 1.13 时代输出如测试快照、文档示例比对时可组合使用import numpy as np a np.array(3.14) # 0-d 数组 np.set_printoptions(legacy1.13) # 或直接 np.array2string(a, legacy1.13, stylestr)修复后style参数在 legacy 模式 0d 数组下与正常模式行为一致不再出现静默失效。本次发布的其他收尾性修复除上述三条核心修复外1.14.3 还一并处理了若干次要缺陷见合并 PR 列表PR修复内容#10959修复flags[WRITEBACKIFCOPY]键缺失问题。该标志表示当前数组是某数组的副本释放时需写回其语义在 numpy/_core/_add_newdocs.py#L2727-L2754 的数组标志文档中有详细说明1.14.3 补充了对应的测试与修复#10960check_embedded_lapack中原型缺失下划线导致的构建期检查问题#10961ma/bench.py中的编码回归Issue #10868涉及基准脚本的文本编码处理#10962NPY_TITLE_KEY宏在 PyPy 下的修复。该宏用于识别结构 dtype 字段的 title 键当前仓库中其定义位于 numpy/_core/include/numpy/ndarrayobject.h#L204-L218并在 numpy/_core/src/multiarray/arraytypes.c.src 多处使用#10974PyArray_DiscardWritebackIfCopy相关测试与修复配合 WRITEBACKIFCOPY 写回机制的健壮性完善这些修复共同说明1.14.3 是一个覆盖构造兼容、打印行为、PyPy 兼容、构建脚本、基准脚本等面的综合修补版本而非单纯的功能性版本。贡献者与合并规模发布说明记录了本次发布的完整贡献者名单与合并规模贡献者共 6 人Allan Haldane、Charles Harris、Jonathan March首次贡献标、Malcolm Smith首次贡献标、Matti Picus、Pauli Virtanen合并 PR 共 8 个全部为 bugfix含 1.14 backport。其中 Allan Haldane、Pauli Virtanen 等是当时 NumPy 核心团队长期活跃成员Matti Picus 长期负责 PyPy 兼容相关工作与本版NPY_TITLE_KEY的 PyPy 修复#10962呼应。对后续版本的启示1.14.3 的三条修复在后续版本中留下了清晰的发展线索list-of-lists 兼容的收敛当前仓库中fromrecords的慢路径仍保留FutureWarningnumpy/_core/records.py#L739-L742提示未来将抛错读者在使用旧代码迁移时应有意识地清理 list-of-lists 输入打印系统的持续演进legacy 模式从 1.14 时代的1.13单一取值演进为当前支持1.13、1.21、1.25、2.1、2.2等多档见 numpy/_core/arrayprint.py#L384-L3870d 数组打印差异、style/suffix等参数的对齐逻辑也随之不断修正Python 2 支持的历史节点本版是 Python 2.7 仍在官方支持列表内的版本而后续 1.15/1.16 起逐步收紧 Python 2 支持直至 NEP 14 之后彻底移除——本文涉及的tp_print相关修复也随 Python 2 退役而成为历史代码路径但其跨版本输出一致性的设计思路在测试框架中仍具参考价值。小结NumPy 1.14.3 是一个小而精的补丁版本三条核心修复分别落在记录数组输入的向后兼容fromrecords、Python 2/3 打印输出一致性tp_print覆盖与legacy 打印模式细节style 0d 数组三个方向另有 5 个收尾性缺陷修复。对于需要维护历史版本行为、编写跨 Python 版本兼容代码或研究 NumPy 打印系统与 recarray 构造机制演进的开发者本文梳理的源码位置numpy/_core/records.py、numpy/_core/arrayprint.py、numpy/ma/mrecords.py与发布说明doc/source/release/1.14.3-notes.rst可互为印证作为继续深入的第一手资料。赞分享科学计算数据分析【免费下载链接】numpyThe fundamental package for scientific computing with Python.项目地址https://gitcode.com/gh_mirrors/nu/numpy点击查看免费下载相关推荐NumPy 1.19.3 维护版本解析Python 3.9 支持、OpenBLAS 修复与稳定性补丁全解读NumPy 1.19.3 维护版本解析Python 3.9 支持、OpenBLAS 修复与稳定性补丁全解读 NumPy 1.19.3 是 NumPy 1.19科学计算数据分析NumPy 2.4.2 补丁版本解析12 个合并 PR 背后的 bug 修复与维护细节NumPy 2.4.2 补丁版本解析12 个合并 PR 背后的 bug 修复与维护细节 导读 NumPy 2.4.2 是 2.4 系列的一个补丁patch科学计算数据分析yfinance版本兼容Python 2.7到3.6的兼容性指南yfinance版本兼容Python 2.7到3.6的兼容性指南 痛点Python版本碎片化带来的兼容性挑战 还在为Python 2.7到3.x的版本兼容数据分析金融科技上一篇终极网络优化指南ET框架如何用MemoryPack实现零GC高性能序列化下一篇OptiScaler打破显卡壁垒的全平台超分辨率解决方案终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考