登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  业界新闻

Python 3.15 candidate 2 发布后扩展作者要先测什么

来源:17golang原创

时间:2026-09-08 20:53:20 479浏览 收藏

Python 3.15 candidate 2 的正式版本名是 Python 3.15.0rc2,不是一个可以直接替换生产环境的普通小版本。官方在 2026 年 9 月 1 日发布它时说明,这是 3.15 的最终计划候选版本,正式版预计在 2026 年 10 月 1 日发布;从这个阶段开始,3.15 系列不再计划 ABI 变化,但它仍属于预览版本。

扩展作者现在最该做的是在干净环境中构建并测试 Python 3.15 wheel:先看能否编译和导入,再看 C API、线程模型、异常与资源释放,最后才决定是否把预发布 wheel 放到 PyPI。不要因为 ABI 进入稳定阶段,就跳过运行回归。
要点速览
  • candidate 2 对应 3.15.0rc2,适合生态兼容性测试,不适合作为生产解释器。
  • abi3abi3t 和版本专用扩展的兼容范围不同,Stable ABI 也不能替代行为测试。
  • 预发布 wheel 可以帮助其他项目提前测试;正式发布前仍要保留平台、依赖和关键路径记录。

先把 Python 3.15 candidate 2 的测试边界定清楚

如果项目只使用纯 Python,第一步通常是跑现有测试并处理弃用警告;如果包含 C、C++、Cython、pybind11 或其他二进制扩展,风险点会多一层:构建系统可能找错头文件,wheel 标签可能声明过宽,模块也可能“能导入但行为不对”。因此不要只把 python --version 的结果贴到 CI 里,而要把解释器、编译器、架构和 wheel 类型一起记录。

官方 release 页面把 3.15.0rc2 标为候选预览版,并明确建议第三方项目在这一阶段准备和发布 Python 3.15 wheel。它还说明,针对 3.15 候选版本构建的二进制 wheel 可以用于后续 3.15 版本的测试。这个承诺解决的是版本系列的 ABI 前向兼容问题,不代表每个平台、每个外部库和每段业务逻辑都已经验证。

Python 3.15.0rc2 从候选版本、C 扩展构建到 wheel 和运行回归的静态关系图
图1:把 Python 3.15.0rc2 的版本事实、扩展构建、wheel 分发和运行回归分开,避免把候选版消息直接等同于生产可用。

扩展回归要拆成构建、ABI、运行三层

第一层是构建:在没有旧缓存的环境里生成 wheel,确认构建后端、编译器和 Python 头文件来自同一个目标解释器。第二层是 ABI:检查 wheel 文件名、平台标签和项目实际使用的 C API 是否匹配。第三层是运行:导入只是起点,还要调用项目最常用的 C 扩展路径,覆盖异常、引用计数、缓冲区、线程和资源释放。

# 在独立环境中构建,不复用旧的编译产物
python3.15 -m venv .venv-315
. .venv-315/bin/activate
python -m pip install -U pip build
python -m build --wheel --outdir dist-315

# 用目标解释器安装并执行最小导入检查
python -m pip install --force-reinstall dist-315/*.whl
python -c "import your_extension; print(your_extension.__file__)"

这里的导入命令只是在确认动态模块能被加载。真正的回归应调用项目已有测试,特别是会分配大块内存、接收 Python buffer、释放外部句柄或跨线程回调的路径。若构建失败,先保留完整编译器错误;若导入失败,再看模块标签、动态库依赖和解释器架构;若导入成功但测试失败,优先定位行为变化,不要盲目把问题归咎于 ABI。

现象优先检查不能直接推出的结论
编译找不到符号或头文件头文件、构建后端、编译器和 C API 使用范围不等于 Python 3.15 本身不可用
wheel 能安装但模块不能导入平台标签、动态库依赖、架构和 ABI 标签不等于源码一定要重写
导入成功,核心测试异常引用计数、线程、buffer、异常和清理路径不等于换成 abi3 就能修复

abi3、abi3t 和版本专用 wheel 不能混为一谈

Python 3.15 文档把 Stable ABI 分成不同目标:abi3 面向非 free-threaded 的 CPython 构建,abi3t 是 3.15 新增、面向 free-threaded 构建的稳定 ABI。若扩展同时满足两套接口和实现约束,可以为两类构建提供兼容包;否则应诚实声明自己支持的解释器和线程模型。

这也是为什么要先查项目源码:使用私有的 _Py_* 接口、版本专用结构布局或没有线程安全边界的全局状态时,简单改一个 wheel 标签并不能创造兼容性。官方文档还提醒,Stable ABI 主要防止链接符号、结构布局和函数签名一类 ABI 问题,不能保证扩展在不同 Python 版本上的行为完全相同;支持多个小版本时仍应逐个测试。

Python 3.15 扩展 wheel 矩阵对比 abi3、abi3t、版本专用 ABI 与平台运行回归
图2:按 Limited API、free-threaded 支持和平台拆分 wheel 矩阵;兼容标签与运行行为是两张不同的检查表。

发布前用一张决策表判断改源码还是改打包

如果旧源码依赖私有 C API,修复方向通常是替换公开接口并补回归;如果源码能编译但 wheel 标签过窄或过宽,优先修正构建配置和发布矩阵;如果只有某个外部库失败,就把依赖版本、编译选项和平台单独锁定后重测。每次只改变一个变量,才能把候选版本带来的问题与构建链变化区分开。

检查结果下一步发布动作
源码构建、导入、关键测试均通过补齐目标平台和依赖组合可发布预发布 wheel 供生态测试
只有标签或构建配置不匹配修正构建后端、元数据或 wheel 矩阵不要用错误标签覆盖旧包
核心行为或线程测试失败保留最小复现并修复源码暂停该平台正式发布

预发布 wheel 的价值是尽早让下游项目发现问题,不是提前宣布生产兼容。官方 release 页面仍把 3.15.0rc2 定义为 preview,并建议生产发布等待稳定版。维护者可以在项目文档、CI 和 PyPI 预发布版本中标明解释器、平台、wheel 标签和已知限制,等正式版发布后再按相同矩阵做一次确认。

常见问题

Python 3.15 candidate 2 和 3.15.0rc2 是两个版本吗?

不是。candidate 2 是便于理解的说法,官方版本号是 3.15.0rc2。下载和 CI 配置应以正式版本号为准。

官方说不再有 ABI 变化,还需要测每个平台吗?

需要。ABI 稳定不覆盖编译器、系统库、架构、第三方依赖和扩展自身的运行语义;这些仍需按项目支持矩阵测试。

把扩展改成 abi3 后可以跳过 Python 3.15 回归吗?

不可以。abi3 只约束一部分 C API 和 ABI 兼容范围,异常、线程、资源清理以及业务行为仍可能变化。

现在能不能直接把 3.15.0rc2 用在生产?

不建议。它适合隔离环境、CI 和生态兼容性测试;生产切换应等待稳定版,并按同一套 wheel 与关键路径检查重新确认。

对 C 扩展作者来说,candidate 2 的优先级很明确:先构建,再确认 ABI 标签,然后跑真实运行路径,最后发布预发布 wheel 收集下游反馈。把每层证据分开记录,比只看一次导入成功更能提前发现正式版上线后的兼容问题。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>