Python 没有官方 RFC，只有 PEP（Python 增强提案）；RFC 是 IETF 术语，PEP 才是 Python 的标准流程，如 PEP 584 定义字典合并操作符 |。
Python 的 RFC 是什么，它真的存在吗
Python 没有官方 RFC（Request for Comments）流程。这个说法常源于对 Python 增强提案（PEP）的误称——RFC 是 IETF 标准体系下的术语，而 Python 用的是 PEP。混淆它会导致你在查资料时跑偏，比如搜 “Python RFC 584” 会找不到任何结果，但搜 “PEP 584” 就能立刻定位到合并字典操作符 | 的规范。
什么时候该去读 PEP，而不是看文档或 Stack Overflow
当你遇到以下情况，直接查 PEP 是最高效的：
- 解释器报错信息里明确提到了
PEP XXX（例如SyntaxError: invalid syntax伴随PEP 634提示，说明你用了不兼容的模式匹配语法） - 想确认某个特性是否“被标准认可”，而非第三方库的临时实现（比如
match/case是PEP 634定义的，不是pydantic自创的） - 在写工具链或 lint 规则，需要知道某行为是“必须支持”还是“可选建议”（
PEP分类中，Standards Track类型才具约束力）
注意：PEP 不是教程。它不教你怎么写 match，而是定义 match 在 AST 层怎么解析、在 bytecode 里如何生成、哪些语法必须拒绝。想快速上手，先看 docs.python.org；想搞清边界和例外，再翻 PEP。
怎么高效定位和阅读一个 PEP
别从 python.org/peps 页面一页页翻。真实使用中，你只需要记住三个入口：
立即学习“Python免费学习笔记（深入）”；
- 搜索
site:peps.python.org PEP XXX（把 XXX 换成编号，如PEP 604），这是最稳的直达链接 - 在终端运行
python -m pydoc -p 8000，然后访问localhost:8000，搜索框里输PEP可看到本地已安装版本对应的 PEP 摘要（适合离线查PEP 563这类影响from __future__ import annotations的） - GitHub 上看
python/peps仓库的pep-XXXX.rst原文，尤其关注Status字段：要是写着Deferred或Rejected，就别在生产代码里当真
阅读时跳过 Abstract 和 Rationale，直奔 Specification 和 Backwards Compatibility 小节。比如 PEP 618（带默认值的 zip）里明确写了“新增 strict 参数，默认为 False”，这就够你写代码了。
团队内部要不要模仿 PEP 做技术决策流程
小团队或项目级“伪 PEP”容易变成流程负担。真正值得借鉴的只有两点：
- 每个重大变更必须附带一个文本文件，标题含编号和短名（如
PEP-001-add-type-hints.md），且明确写清Status: Draft / Accepted / Rejected - 关键决策点必须引用 Python 官方
PEP编号（例如“本方案不兼容PEP 563的延迟求值，因需运行时反射”），而不是模糊说“按 Python 最佳实践”
没写清楚 Status 的文档，半年后没人知道它是待讨论草案还是已落地规范。这比要不要用 Markdown 写更重要。
