Python 3.15.0rc3 意外登场：在正式版前再做一轮兼容性体检

2026-10-02 19 预计阅读时间: 1 分钟
来源: blog.python.org AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：8 分钟

Python 3.15.0 迎来了一个“传统式惊喜”：额外发布的第三个候选版本 rc3。现有信息没有说明这次追加候选版本的具体原因，也没有给出新的功能清单，因此不宜把它解读为功能更新。对应用和库的维护者来说，更实际的动作是把 rc3 当成正式版前新增的一次验证窗口。

rc3 的意义不在于追新，而在于缩小未知范围

Release Candidate 阶段的核心任务是稳定性验证。出现 rc3，意味着团队可以用更接近最终版本的解释器，再跑一遍真实项目、依赖安装和发布流程。

值得重点检查的不是一段简单的 print("hello")，而是项目中容易暴露版本差异的位置：

  • 带有 C、C++ 或 Rust 扩展的依赖能否构建和导入；
  • 打包工具是否能够正确识别 Python 3.15；
  • 单元测试之外，命令行入口、异步任务和子进程是否正常；
  • 项目是否依赖已弃用接口，或把警告当成错误处理；
  • 类型检查、代码覆盖率和调试工具是否支持新解释器；
  • 部署镜像、构建脚本和版本判断是否写死了旧版本范围。

rc3 并不意味着生产环境应立即升级。它更适合作为兼容性目标加入非阻塞 CI，提前找到问题，同时保留现有稳定版作为正式发布和部署基线。

用独立虚拟环境运行一次完整测试

假设你已经通过系统包管理器、源码构建工具或版本管理器安装了 Python 3.15.0rc3，可以执行下面的脚本。运行前，把 PYTHON_BIN 改成 rc3 解释器的实际路径；脚本会主动验证版本，避免误用其他 Python。

#!/usr/bin/env bash
set -euo pipefail

PYTHON_BIN="${PYTHON_BIN:-python3.15}"

"$PYTHON_BIN" - <<'PY'
import sys

print("Testing with:", sys.version)
assert sys.version_info[:2] == (3, 15), sys.version
assert sys.version_info.releaselevel == "candidate", sys.version_info
assert sys.version_info.serial == 3, sys.version_info
PY

rm -rf .venv315rc3
"$PYTHON_BIN" -m venv .venv315rc3
. .venv315rc3/bin/activate

python -m pip install --upgrade pip

# 按项目实际情况保留其中一种安装方式。
if [ -f pyproject.toml ]; then
  python -m pip install -e '.[test]'
elif [ -f requirements.txt ]; then
  python -m pip install -r requirements.txt
fi

# 先编译源码，尽早发现语法或导入路径问题。
for path in src tests; do
  if [ -d "$path" ]; then
    python -m compileall -q "$path"
  fi
done

# 如果项目使用 pytest，则运行完整测试集。
if python -c 'import pytest' 2>/dev/null; then
  python -m pytest -q
fi

如果项目的测试依赖不是通过 .[test] 声明的，需要把安装命令替换成自己的开发依赖，例如：

python -m pip install -r requirements-dev.txt

不要只记录“测试失败”。还应区分失败发生在哪一层：

  1. 解释器行为变化：纯 Python 代码在 rc3 下产生不同结果；
  2. 第三方依赖未适配：依赖拒绝安装、没有可用 wheel，或原生扩展编译失败；
  3. 工具链问题：测试、覆盖率、打包或静态分析工具尚未识别 3.15；
  4. 项目自身限制：pyproject.toml、环境标记或版本判断排除了 3.15。

这种分类决定了问题应该提交给 CPython、上游依赖，还是由项目自己修复。

检查版本约束，避免自己挡住 3.15

不少项目的代码本身可以运行，但元数据仍把新版本拒之门外。例如下面的配置会排除所有 Python 3.15 环境：

[project]
requires-python = ">=3.10,<3.15"

确认测试通过后，可以这样调整：

[project]
requires-python = ">=3.10,<3.16"

修改上限前应完成测试，而不是仅凭版本号推测兼容性。如果项目并不需要人为设置上限，也可以评估是否删除上界，只保留真实的最低版本要求：

[project]
requires-python = ">=3.10"

同时搜索代码中手写的版本分支：

grep -RInE 'python_requires|requires-python|version_info|3\.14|3\.15' \
  pyproject.toml setup.py setup.cfg src tests 2>/dev/null || true

版本判断最好围绕具体能力编写。若只是为了判断某个 API 是否存在，优先使用特性检测，而不是假定某个 Python 版本必然具备或缺少该能力。

把 rc3 放进 CI，但暂时不要让它阻塞发布

候选版本最适合成为测试矩阵中的实验项。可以这样实践：稳定版本失败时阻塞合并，3.15.0rc3 失败时产生清晰告警和问题单，但暂不影响生产发布。

为避免“允许失败”变成长期忽略，建议给 rc3 测试设置明确的退出条件：

  • 记录失败的依赖名称、版本和错误日志；
  • 对原生扩展分别验证源码构建与 wheel 安装；
  • 在 Python 3.15.0 正式版发布后，将实验任务改为必过；
  • 不要因为 rc3 测试成功，就立即删除当前稳定版本的测试任务；
  • 生产部署仍应等待依赖、运行时镜像和监控工具完成支持确认。

采用前的简短清单

Python 3.15.0rc3 的价值，是让兼容性问题在正式升级之前暴露。维护者可以按下面的顺序行动：

  • 安装独立的 rc3 解释器，不覆盖开发机和生产环境中的稳定版；
  • 完成依赖安装、源码编译、单元测试和关键业务冒烟测试；
  • 检查打包元数据、版本上限及平台条件标记；
  • 单独关注原生扩展、异步代码、子进程和开发工具链；
  • 把失败归因到解释器、依赖、工具或项目配置；
  • 在正式版到来后重新测试，不把 rc3 的结果视为永久保证。

这次“意外”的 rc3 不需要引发升级焦虑。更合理的做法，是利用它多获得一轮反馈，把未来的正式升级从一次冒险变成一次已经演练过的变更。

# Python # 后端

相关推荐