企业官网建设流程全解析

• 编程语言
• 语言运行时
• 解释器
• 标准库

CPython 每次发布版本都会在仓库中沉淀一份规范的变更记录（news entry），本文基于 Misc/NEWS.d/3.5.0rc4.rst 这份真实历史文档，剖析 CPython 3.5.0rc4（2015-09-09 发布）的两条关键变更：修复test_strptime中出现的MemoryError，以及回退部分静态构建选项并为 Windows 安装包补充vcruntime140.dll。读完本文，你将理解 CPython 新闻条目的元数据格式、strptime的底层实现与测试体系，以及 Windows 下 Python 与 MSVC C 运行时的依赖关系。

一、先读懂这份文档：CPython 的 blurb 新闻条目格式

Misc/NEWS.d/3.5.0rc4.rst是 CPython 专门存放"按版本组织的发布变更"的目录。当前仓库中Misc/NEWS.d/下共有 119 个文件，覆盖 3.10.0a1 至 3.14 的各 alpha/beta/rc 版本（如 Misc/NEWS.d/3.13.0a1.rst），更早的历史则归档在 Misc/HISTORY 中。

这份文件采用 CPython 新闻工具链（blurb）的标准条目格式，每个条目由一组 RST 注释元数据加一行正文组成：

.. bpo: 25029 # 关联的 Python bug 跟踪单号 .. date: 9304 # 条目的排序序号（越大越新） .. nonce: Zf97rk # 防止哈希冲突的随机串，用于唯一标识条目 .. release date: 2015-09-09 # 该版本的实际发布日期 .. section: Library # 变更所属的分类（如 Library / Build / Core and Builtins） Fixes MemoryError in test_strptime.

其中.. section:的取值决定了这条新闻在最终发布说明中的归类。对当前仓库全部Misc/NEWS.d条目做统计，可以看到主要的分类及其体量：Library（7916 条）、Core and Builtins（3444 条）、Build（752 条）、C API（695 条）、Tests（694 条）、IDLE（527 条）、Windows（515 条）、Documentation（511 条）、Security（218 条）、Tools/Demos（190 条）、macOS（133 条）。本文涉及的两条恰好分属Library（库层修复）与Build（构建系统变更）两个典型分类。

3.5.0rc4属于 3.5.0 正式版之前的第四个发布候选版本，.. release date: 2015-09-09明确标注了其发布时间。整个文件仅两条新闻，正是 rc（候选发布）阶段"只做修复、不再引入新功能"的典型形态。

二、bpo-25029：修复 test_strptime 中的 MemoryError

2.1 变更内容

第一条新闻（section: Library）正文只有一句话：

Fixes MemoryError in test_strptime.

即：修复了test_strptime测试在执行过程中可能抛出的MemoryError（内存分配失败错误）。这类修复通常意味着在某个运行环境下，测试代码或被测代码存在导致异常内存占用/分配失败的问题，通过本次改动使该测试在各种环境下都能稳定通过。

2.2 strptime 的底层实现（当前仓库可对照的源码）

strptime是 Python 中把字符串按格式指令解析为时间元组的函数，与strftime（格式化输出）互为逆操作。其纯 Python 实现位于 Lib/_strptime.py，模块头部注释清晰说明了内部结构：

• LocaleTime：发现并存储与区域设置（locale）相关的时间信息（星期名、月份名、AM/PM 表示等）；
• TimeRE：把格式字符串编译为正则表达式，用于对输入文本做模式匹配；
• _getlang()：探测当前LC_TIME区域设置（见 Lib/_strptime.py）；
• _strptime()：核心入口，计算输入字符串所表示的时间结构体（见 Lib/_strptime.py）。

特别值得注意的是_strptime()中的缓存机制（见 Lib/_strptime.py）：模块维护了全局的_TimeRE_cache（区域时间信息缓存）与_regex_cache（已编译正则缓存，上限_CACHE_MAX_SIZE = 5），并用_cache_lock保证多线程安全。当_getlang()、time.tzname或time.daylight发生变化时，缓存会被整体重建。从源码结构看，strptime的正确性与性能高度依赖"区域信息探测—正则编译—缓存"这条链路，测试中的内存问题也往往与这类编译/缓存路径上的资源消耗相关。

2.3 测试体系：test_strptime.py 在验证什么

与_strptime.py对应的是体量达 961 行的 Lib/test/test_strptime.py，它覆盖了：

• getlang_Tests：验证_getlang()与locale.getlocale(locale.LC_TIME)一致；
• LocaleTime_Tests：把strftime的%A/%a/%B/%b/%p等输出与LocaleTime存储的元组逐一对照，校验星期名、月份名的内容与位置；
• strptime_Tests等：对%Y、%U/%W周数、儒略日换算等指令做正向与负向断言。

测试文件还导入了test.support中的skip_if_buggy_ucrt_strfptime装饰器（见 Lib/test/test_strptime.py），用于在 MSVC UCRT 存在已知strptime/strftime缺陷的 Windows 环境下跳过部分用例——该装饰器在 Lib/test/support/init.py 中实现：当平台为 win32、locale 编码为cp65001且time.localtime().tm_zone为空字符串时，判定 UCRT 存在缺陷并跳过测试。这反映出strptime家族测试对"平台 + 区域 + C 运行时"组合的高度敏感，也正是 bpo-25029 这类"测试中偶发 MemoryError"需要专门修复的原因。

三、bpo-25027：回退部分静态构建选项，Windows 安装包加入 vcruntime140.dll

3.1 变更内容

第二条新闻（section: Build）正文：

Reverts partial-static build options and adds vcruntime140.dll to Windows installation.

包含两层含义：

1. 回退部分静态构建选项（reverts partial-static build options）：构建系统在 rc 阶段收回了此前引入的"部分静态"构建相关改动，避免其对发布构建造成不确定影响；
2. 在 Windows 安装中补充vcruntime140.dll：把 MSVC 的 C 运行时 DLL 随 Python 一并分发，保证python.exe在未预装该运行时的目标机器上也能直接运行。

3.2 静态/共享构建选项在源码中的痕迹

"部分静态（partial static）"指构建产物中一部分库采用静态链接、一部分采用共享链接的混合形态。当前仓库 configure.ac 中仍完整保留着这一维度的配置能力，可以佐证构建系统长期维护的相关选项：

• --enable-shared：是否构建共享的 Python 库（默认否），见 configure.ac；
• --with-static-libpython/--without-static-libpython：是否生成静态libpython，见 configure.ac；
• --enable-static-libpython-for-interpreter：是否为解释器单独启用静态libpython，见 configure.ac 附近。

从源码结构看，这些选项的组合即构成"全静态/全共享/部分静态"等不同构建形态；3.5.0rc4 对该方向的选项做回退，说明当时存在与发布构建不兼容的风险点，属于发布前的保守收敛。

3.3 vcruntime140.dll：Python 与 MSVC C 运行时的关系

Windows 上的 CPython 由 MSVC（Visual C++）编译，运行时依赖对应的 C 运行时库。vcruntime140.dll对应 Visual Studio 2017 使用的 C 运行时版本 14.0。PCbuild/readme.txt 明确指出：

Visual Studio 2017 uses version 14.0 of the C runtime (vcruntime140). The executables no longer use the "Side by Side" assemblies used in previous versions of the compiler. This simplifies distribution of applications.

即从 VS2017 起可执行文件不再依赖"并行程序集（Side by Side）"机制，运行时库可以直接以 DLL 形式随应用分发，这使"把vcruntime140.dll放进安装包"成为简化部署的可行方案。

当前仓库的工程文件 PCbuild/pythoncore.vcxproj 中保留了_CopyVCRuntimetarget（AfterTargets="Build"），在构建完成后把VCRuntimeDLL复制到输出目录，并附带一条注释（对应 bpo-38597）："When we switch to another VCRuntime DLL, include vcruntime140.dll as well"——即无论切换到哪个版本的 VC 运行时，vcruntime140.dll都需要一并提供。这印证了该 DLL 对 Python 运行时的基础性地位。

在安装包/目录布局层面，PC/layout/main.py 会在布局过程中从构建目录递归查找vcruntime*.dll并复制进输出目录，找不到则报错；PC/layout/support/python.props 也把$(PythonHome)\vcruntime140.dll显式列入运行时文件清单；PC/layout/README.md 同样说明布局打包时通过vcruntime*通配规则收集该 DLL。由此可见，"安装中包含vcruntime140.dll"已经固化为当前构建与打包流程的标准行为。

3.4 实际操作：如何在 Windows 上构建并验证

若要复现相关构建行为，可参考当前仓库 PCbuild/build.bat 提供的命令行入口（其-h帮助文本列出了全部参数）。典型用法：

PCbuild\build.bat :: 默认 Release / x64 配置构建 PCbuild\build.bat -d -p Win32 :: Debug + 32 位平台 PCbuild\build.bat --pgo :: 启用 Profile-Guided Optimization

构建完成后，pythoncore.vcxproj的_CopyVCRuntimetarget 会把运行时 DLL 复制到$(OutDir)（如PCbuild\win32或PCbuild\amd64），随后用PCbuild\rt.bat即可运行刚构建的python.exe做冒烟验证。安装包布局则由PC/layout/下的工具完成，其rglob(ns.build, "vcruntime*.dll")逻辑（PC/layout/main.py）保证了安装目录中一定包含运行时。

四、历史档案价值：如何继续追查这两条变更

Misc/NEWS.d/3.5.0rc4.rst这类文件本身即 CPython 的历史档案。若想进一步追查 bpo-25029 与 bpo-25027 的来龙去脉，仓库内还有两条线索：

1. SVN 提交映射表Misc/svnmap.txt 中记录了 bpo 25027 与 25029 对应的提交哈希，可据此回溯当时的源码改动；
2. 当前实现继续演进：strptime的实现与测试仍在持续维护（如_calc_julian_from_U_or_W对%U/%W周数换算的处理见 Lib/_strptime.py，测试中的 UCRT 缺陷跳过逻辑见 Lib/test/support/init.py），Windows 运行时打包机制也在PCbuild与PC/layout/中不断强化——这正是从一条 3.5 时代的新闻条目出发，沿着源码与测试把历史问题映射到当代实现的研究方法。

小结

本文围绕 Misc/NEWS.d/3.5.0rc4.rst 逐条还原了 CPython 3.5.0rc4 的两项发布前修复：Library 分类下的test_strptimeMemoryError 修复，以及 Build 分类下对部分静态构建选项的回退与vcruntime140.dll随安装分发的调整。通过Lib/_strptime.py、Lib/test/test_strptime.py、PCbuild/pythoncore.vcxproj、PC/layout/等当前仓库文件，可以确认这两类问题在当代代码库中的持续存在形态与防护机制，也让这份十余年前的发布记录具备了可对照、可验证的技术价值。

• 编程语言
• 语言运行时
• 解释器
• 标准库