先讲一个工程师的委屈。
某天，一位 Meta 的工程师盯着屏幕，执行了一条命令。他只是想看看帮助文档，就那么一行，不需要计算，不需要联网，不需要任何复杂操作。但程序停顿了一下。就那么短短一下，却已经足够让他皱眉。
他知道发生了什么。Python 正在后台搬家具——把一堆这次根本用不上的模块，老老实实一件一件装进内存。就因为代码文件的开头写了几行 import，解释器就默认你全都要，没有任何商量的余地。
这种感觉就像你出门买包烟，外卖平台却提示你「已为您备好今日三餐」。
这位工程师的感受，不是矫情，而是在 Meta 这种规模的公司里，每天重复着真实的成本。他们有一套叫 Cinder 的内部 Python 分支，专门对解释器做了各种改动，其中有一项，就是把很多顶层导入改成了「不急，等用到再说」。效果很好——程序启动速度大幅提升，内存占用也降了下来。量化交易公司 Hudson River Trading 后来也在自己内部实现了类似方案，专门写了一篇文章谈到，这套做法在整个公司的 Python 环境里都铺开了，用来解决大型代码库里长期存在的启动慢问题。
两家公司，做了同样的选择，还都跑通了。
2022 年，这个想法终于变成了一份正式提案。
在 Python 的世界里，任何想对语言本身做出改动的人，都必须走一套叫做 PEP 的流程——全称是「Python 增强提案」（Python Enhancement Proposal）。它不是随便发个帖子提建议，而是一份要求完整背景、清晰方案、充分论证的正式文件，提交之后需要经过整个社区的公开审查和讨论，最终由指导委员会决定是否接受。这套制度，是 Python 社区所有重要变化的正式入口。
这一次提案的编号，是 PEP 690。
提案写得很清楚：给 Python 加一个开关，让延迟导入可以被打开。打开之后，import 不再立刻执行，而是先放着，等代码真正去用这个名字的时候，再触发真实加载。名字不变，用法不变，只是执行时机往后挪了一挪。
这件事看起来几乎无懈可击。
然后，它被拒了。
拒绝它的，是 Python 的指导委员会。
在聊指导委员会之前，得先绕一点路，说说 Python 这门语言是怎么走到今天的。
故事要从 1989 年的圣诞节说起。荷兰程序员 Guido van Rossum 利用假期无聊的时光，开始写一门新语言，「就当打发时间」。谁也没想到，这个「打发时间」的项目，三十年后成了全球使用最广泛的编程语言之一。
Guido 在社区里有个头衔，叫「终身仁慈独裁者」，英文缩写 BDFL。这个名字听着像在开玩笑，但它的分量一点都不轻：在所有关于 Python 的重大争议面前，只要 Guido 开口，就是最终答案。他的判断从来都不是任性，而是建立在对语言几十年的理解和对生态的深度感知上。社区信任他，所以赋予他这个权力；而他也确实用了几十年的时间，把这份信任还了回去。
可这套模式毕竟有极限。
2018 年，一场关于「海象运算符」的争论把整个社区搅乱了。那个符号长这样：:=，用途是在表达式里同时完成赋值和返回值。很多人觉得它很有用，另一批人觉得它让代码变得费解，然后双方开始在邮件列表、论坛、各种角落里吵架，言辞越来越激烈，情绪越来越难看。Guido 最终接受了这个提案。结果换来的不是掌声，而是更多的质疑。
他在宣布退位时留下的意思很清楚：不想再在一个让自己筋疲力尽的地方，继续扮演那个最后拍板的人。
于是，Python 失去了它的终身仁慈独裁者。
社区沉默了一阵，然后开始讨论：接下来怎么办？
他们给出的答案，是一套被写进 PEP 13 的治理框架：指导委员会。五名成员，由核心开发者投票选出，任期与 Python 的版本发布周期大致对应。它不是一个发号施令的机构，更像一个维持秩序、推动共识、在必要时最终拍板的地方。
而且它有一条很有意思的规定：五名委员里，最多只能有两名来自同一家公司。这条规定存在的理由非常直白——Python 生态里不乏 Meta、微软、谷歌这样的巨头，他们对语言的走向当然有影响力，但 Python 不能变成某一家公司的后花园。所以哪怕某公司的人真的选上了三席，得票最低的那位也会被取消资格，名额顺延给别人。
这条规定从未被动用过，但它在那里。它存在的意义，不在于被触发，而在于让所有人知道，这条边界画在哪里。
现在可以回到 PEP 690 的故事了。
指导委员会看完这份提案，想了很久。
延迟导入这件事本身，委员们并不觉得没有价值。Meta 和 Hudson River Trading 的实践数据摆在那里，现实需求是真实的。但他们担心的，是一个更深层的问题。
Python 现在有多少代码在运行？没有人能给出精确数字，但可以大致感受一下：全球几百万个项目，各种行业、各种规模，大到航天数据处理，小到学生作业脚本，很多都在跑 Python。这些代码，写的时候没有人告诉它们，有一天 import 的时机会发生变化。
如果全局打开延迟导入，会发生什么？大部分代码可能没有问题。但「可能没有问题」和「一定没有问题」之间，差的那一段，在这个规模下，就是无数个潜在的 bug。
更具体的担忧是这样的：Python 里有一种常见用法，导入一个模块本身就是为了触发它的副作用——注册某个钩子、初始化某个全局状态、填充某张配置表。这类代码写的时候，假设是「import 之后马上生效」。但如果延迟导入默认打开，这些副作用会推迟发生，推迟到第一次真正用到模块名字的时候。如果代码里有哪个地方依赖这个副作用在某个时刻之前已经发生，就会悄悄出错，而且很难追查。Hudson River Trading 自己后来也承认，他们在迁移过程中确实遇到过这类问题。
除此之外，PEP 690 的实现依赖对 Python 底层字典访问语义的特殊处理。这是解释器里相当核心的部分，一旦改动，整个调试、测试、类型检查工具链都可能受到影响。
指导委员会给出的裁定措辞很谨慎，但态度很明确：这份提案先暂停，不进官方。
PEP 690 死了，但它没有消失。
它更像是一场探路，把所有真正的问题都引出来了：哪里最脆弱，哪里最容易出错，什么情况下会引发麻烦，什么样的方案才能让委员会放心。
三年后，PEP 810 出现了。
和 690 最大的不同，是它不再试图改变默认行为。它不去碰「所有 import 默认变懒」这个最敏感的开关，而是引入显式语法，让开发者自己决定哪一行导入要延迟。你要用，你就标出来；你不标，就跟从前一模一样。
这个改变，让整件事的政治风险几乎瞬间消解了。
因为不再是全局的，就意味着不会强迫任何人承担不想承担的风险。库作者不需要重新测试全部代码，工具链不需要应对一种新的默认语义，那些依赖副作用时机的老代码也不会被悄悄影响。延迟导入依然存在，只是把选择权还给了最清楚自己代码的人。
实现上，PEP 810 也比 690 更收敛。它用代理对象来处理延迟加载的名字：import 时先返回一个轻量的占位对象，等代码真正去访问它时，再触发实际加载。这种做法不需要改动底层字典的访问语义，干扰面更小，诊断起来也更直接。
2025 年 11 月，指导委员会全票通过了 PEP 810。它将在 Python 3.15 里落地，预计 2026 年 10 月与大家见面。
说到这里，不妨再说说 PEP 这套档案本身。
如果你有机会去翻 Python 历史上的 PEP 列表，会发现这个档案库其实比任何编程书都好看。它记录了 Python 所有重要变化的来龙去脉，从提案到争论到妥协到落地，每一步都在上面。你可以看到一个想法是怎么从草稿变成正式提案，经过多少轮讨论，被哪些人质疑，最后用什么方式通过或者被否决。它不只是技术文档，更像一部正在进行中的语言编年史。
里面当然有改变 Python 气质的大提案：PEP 8 统一了整个社区的代码书写习惯，让来自不同地方的程序员写出的代码读起来像同一种语言；PEP 20 写下了 Python 的审美宣言——「优美胜于丑陋，简单胜于复杂」，在代码里敲下 import this，就能看到这段被当成彩蛋藏起来的编程圣经；PEP 484 把类型提示正式带进了 Python，让这门动态语言在大型工程里也站稳了脚跟。
但里面也有让人哑然失笑的东西。PEP 404，编号选得太妙，借用了人人都懂的「404 Not Found」，用来庄严宣布「Python 2.8 不会存在」。还有 PEP 401，一篇发布于愚人节、写得煞有介事的恶搞提案，假模假式地讨论把 != 换成古早的 <> 符号。
这些「玩笑提案」存在的意义，不是破坏制度的严肃性，反而恰恰证明了这个社区的健康：一帮长期处理严肃事务的人，还有余裕在规则体系内部留一点给自己的幽默感。
当然，Python 背后的世界不只有 PEP 和指导委员会。
还有一个叫 PSF 的存在，Python 软件基金会（Python Software Foundation）。它不写代码，不制定语法，也不参与技术争论。但它在那里，支持着整个生态的基础运营：活动、文档、教育推广、社区协调、基础设施。那些你用起来觉得理所当然的东西，背后往往都有它的参与。
一个开源项目能走多远，技术只是一部分，另一部分靠的是有没有人把松散的热情转化成稳定的组织能力。PSF 做的，就是这件事。
说到这里，有一件事很值得专门讲：华人开发者在这套系统里，已经早就不只是旁观者了。
这件事有一条很清晰的脉络。
时间拨回到 Python 早年在中文社区生根的阶段。当时，中文世界和 Python 核心开发之间，最大的障碍之一，其实不是技术，而是语言。Python 的官方文档全是英文，对绝大多数国内开发者来说，这是一道很实在的门槛。
为了推动官方文档的翻译工作走上正轨，需要的不只是一群愿意出力的志愿者，还需要一套被官方认可的标准。PEP 545 正是要解决这件事——建立一套规范的文档翻译流程，让各语言版本的译文能被官方系统正式收录并对外发布。核心开发者张翔（Xiang Zhang）是当时中文翻译社区里最活跃的推动者之一，他对中文翻译现状的判断被 PEP 545 专门引用，也成为提案能够推进的重要依据之一。PEP 545 最终在 Python 3.7 里落地。今天你能在 Python 官网直接切换到中文文档，这件事在技术上的起点，就在这里。
而在今天，华人开发者参与的层次又往前走了很远。
如果你这几年开始写 Python，应该越来越习惯用 pyproject.toml 来配置项目，而不是那个又老又难用的 setup.py。这套新的项目元数据标准背后，有来自台湾的开发者 Tzu-ping Chung 的深度参与。他是 Python 和 pip 的核心开发者，也是 PEP 621 的联合作者之一。这份提案把项目元数据的写法标准化进了 pyproject.toml，是今天现代 Python 工程化生态的重要基石。
PDM 的作者 Frost Ming 是另一个例子。PDM 是一款现代 Python 项目管理工具，它的特别之处，在于它往往是社区里最早把纸面上的包管理新标准落地跑通的那一个，用真实工程验证那些提案里描述的能力是否真正可行。很多时候，一个标准从理论走向被广泛接受，需要的正是这样的「第一个真实实现」。
从推动文档翻译走向规范，到参与制定项目元数据标准，再到用工具率先落地新提案——这条路走了不短的时间，但它确实在走，而且已经走到了一个不可忽视的位置。
回到最开始的那位 Meta 工程师。
他当年提交 PEP 690 时，大概没有料到要等三年。他知道的是，这个功能有用，数据支持它，真实场景需要它。他没想到的是，「有用」只是第一步，而「能被整个生态安全消化」才是这条路上更难的一关。
但他也没有放弃。社区也没有。
三年之后，一个更稳妥的版本终于过了委员会这一关。
这件事本身，大概就是理解 Python 最好的方式。
它不是一门靠速度取胜的语言，也不是一套靠个人魅力维系的社区。它更像一个长期在运转的自治体：有规则，有分歧，有博弈，有时候慢得让人着急，但正因为慢得认真，所以才走得这么远。
你每次打开终端，敲下那几个字母，调用的不只是一个解释器。你其实在连接着这三十年里，无数工程师的争论、妥协、坚持和等待。
