摘要

  • Python 的 PEP 流程区分公开讨论、Steering Council 或获批准 PEP-Delegate 的裁决、参考实现、并入主源码仓库，以及发布分支上的不同控制。
  • 一份从裁决到发布的回执应分别固定 PEP、裁决人、决议、代码修订、目标分支、发布阶段和工件，不能把“已接受”自动扩写成“已交付”。

“Python 已接受”到底说的是哪件事

“Python 已接受这个变化”听起来完整，实际可能只指一个 PEP 有了编号，也可能指公开讨论达到了可裁决状态、Steering Council 作出了决定、某位被批准的 PEP-Delegate 对指定 PEP 作出决定、参考实现已经完成，或某个版本最终被切出。这些事情彼此有关，但面对部署、打包和长期维护，它们不是可互换的证据。

PEP 1 先把 PEP 定义为设计文件：它用来说明新功能或流程变化，集中社区输入，并保存设计理由和异议。作者有责任推动共识、记录反对意见。这个过程很重要，因为它让技术判断可被后来者检视；但它不把参与本身变成正式裁决，也不把一份设计文件变成可下载的发布件。

因此，读者应先问“发生了什么动作”，而不是先问“谁说过什么”。编辑审查使文稿合乎格式，不等于接受提案。讨论提供批评和经验，不等于授予发布权。决议确定设计方向，不等于代码已经完成。一次合并关联到实现，不等于某个稳定版本已经产生。顺序中的每一次跳转都应由自己的记录承担。

委托是有边界的判断，不是无限授权

PEP 1 规定，PEP 是否接受的最终权力属于选出的 Steering Council。若有 core developer 认为自己适合对某个 PEP 作最终判断，可以提出担任 PEP-Delegate；经 Council 批准后，该人可以批准或拒绝那个 PEP。对委托人是否合适的担忧，也可以回到 Council 处理。

这不是把 Python 交给某一个人，也不是把 Council 留作象征。它是针对一个确定提案的有限委托：让熟悉议题的人作出裁决，同时保留任命、质疑和最终责任的公开路径。它的边界是指定 PEP，并不自然扩展为对所有语言设计、全部仓库或未来某次发布的支配权。

PEP 13 提供外层结构。五人 Steering Council 有广泛权力，应在正式行动前寻求共识，可以委托部分权力，并在其他办法失败时充当最终上诉场所。正因权力广泛，记录更应能够指出它实际作用在哪一项决定。Council 的存在不会使每次 commit 都成为 Council 决策；Delegate 的名字也不能替代发布工程的证据。

Accepted、Final 与 released 是三种状态语言

PEP 1 的界线很直接：PEP 被接受以后，参考实现必须完成并已纳入主源码仓库，状态才能改为 Final。故而 Accepted 不是“实现已经完成”的同义词。Final 也不是把原先的判断换成更强烈的标签；它把已有的设计裁决与一个完成的参考实现接合起来。

状态词还有另一层限制。暂时接受的 PEP 即使相关变化已经进入某次 Python 发布，仍可能被拒绝或撤回。任何状态都不自动证明长期稳定、所有下游环境兼容、用户已采用，或未来不会有重设计。规则给状态多大含义，读者就应给它多大含义。

开发周期把发布面的控制再分开。新特性在 in-development 的主分支上推进；进入 beta 时建立 maintenance branch，使下一周期可以在 main 上继续，而当前周期被稳定下来。处于 release candidate 时，只允许经过审查、足够严重的错误修复；切出最终版本时，只有 release manager 可以修改该分支。这些限制保护的是一个确定发布窗口，并不倒过来把 release manager 变成每项 PEP 设计的裁决者，也不允许已接受的 PEP 越过稳定化规则。

应当保存怎样的交接回执

关于裁决，回执至少应记录 PEP 编号和版本、规范讨论链接、裁决者、是否存在 Delegate 委托、决议链接和状态；若目标版本、代码完成、回补或发布时间没有被决定，也应如实写明。关于实现，应补充参考修订、仓库、目标分支和公开的测试或审查资料。关于发布，应补充分支、阶段、工件标识、release manager 的操作和公开版本。

这不是要求 Python 增设一套沉重程序。它是一项报道和依赖判断的纪律：不要把讨论变成授权，把授权变成已经完成的代码，再把代码改动变成可安全使用的发布事实。

来源

  1. PEP 1 — PEP Purpose and Guidelines
  2. PEP 13 — Python Language Governance
  3. Python Developer’s Guide — Development cycle
  4. Lu Heng, The Multi-Stakeholder Mirage
  5. Lu Heng, Running-Code Primacy