终于，Python 标准库要做“瘦身手术”了！

最近刷到 Python 官方的讨论区，我整个人都“咦？怎么感觉时代真的变了”。 Python 那个几十年越堆越厚的标准库，终于顶不住压力，要开始做瘦身了。

这事其实不是突然拍脑袋，而是 Python 社区琢磨了好多年：生态变大了、维护成本变高了、库的现代化速度跟不上……一些“上世纪”风味的模块一直躺在里面，占名字空间、占维护成本，还吓跑新人。

为什么要瘦身？不是好好的吗？

Python 的标准库，说白了就像一个永远塞满的工具箱，什么螺丝刀、钳子、锉刀、锯子……但你认真翻一翻，会发现有些工具尘土一厘米厚，仍然被带在身上。

举几个常被吐槽的：

• distutils（几乎没人想再碰）
• cgi / cgitb（网页都没人这么写了）
• asyncore / asynchat（早被 asyncio 时代淘汰）
• smtpd（比不上任何现代库）

这些模块放在标准库里，不仅没人用，还必须继续维护兼容性 —— 想象一下你家门口有口古井，平时没人取水，但你每年还得修它以防塌方，就是这种感觉。

所以官方的目标很直接：把这些“遗留模块”（deprecated modules）移出标准库，搬到 PyPI，继续让愿意的人来维护。

标准库更轻，节奏更快，开发者压力小，新人也少踩坑。

会影响我写代码吗？

大部分人完全不会受影响。 因为你平时根本不会 import 那些东西……你要不是写 Python 十几年了，甚至不知道它们的存在。

比如你可能从来没写过这样的东西：

import cgi
form = cgi.FieldStorage()

又比如这些基本没人写了：

import asyncore
asyncore.loop()

这些库移出标准库后，如果你真的真的是老项目还在依赖，只需要：

pip install cgi

或者

pip install asyncore

就解决了——跟你平常装库没区别。

官方怎么做这次“瘦身手术”？

他们不会一刀切。 整个过程分成几个阶段：

1. 标记废弃（Deprecation）在文档里写明“这个东西下一版本要移除了”，并给替代方案。

2. 发出 PEP（Python Enhancement Proposal）比如 PEP 594 专门列一张“要移除的模块清单”，大家一起确认。

3. 正式从某个大版本中移除例如从 Python 3.13 开始，一批老模块会彻底消失。

4. 同步在 PyPI 发布独立版本想继续用的开发者可以 pip 安装，不影响生态。

这种拆分方式很稳定，不会突然搞你一手，让你线上服务“叉儿”一声挂掉。

都有哪些库要离开？

不完整列表（但大概你看完还是会说“这些我真的不会用”）：

• aifc
• audioop
• cgi
• cgitb
• crypt
• imghdr
• mailcap
• msilib
• nntplib
• smtpd
• telnetlib
• urllib.parse 里的某些过时函数

以及更多“远古时代”风味的模块。

你看，说实话，这些模块大部分早就被更现代的库替代了，比如：

• 网络通信 → asyncio / 第三方库
• Web 开发 → 所有框架（FastAPI、Django、Flask）
• 邮件服务 → email、smtplib 或者外部 SDK
• 图片处理 → Pillow
• 音频处理 → pydub、librosa 等

它们在标准库里存在更多是一种“历史包袱”。

没了这些模块，Python 会变快吗？

严格来说：

✔ 解释器体积会减少

嵌入式、服务器部署镜像都会变小。

✔ 维护成本下降

官方可以把精力放在更重要的模块上（asyncio、pathlib、typing、concurrency）。

✔ 新模块能引入得更快

标准库不再被老模块拖住，可以更频繁推出现代化工具。

✘ 运行速度不会直接变快

代码执行速度还是那样，但开发体验会更轻。

不过这次瘦身的目标主要是“健康长寿”，不是“甩肉减肥”。

老项目会不会被坑？

假如你项目里真的用了要被移除的模块，例如：

import mailcap

升级 Python 后运行就会报：

ModuleNotFoundError: No module named 'mailcap'

你的做法只有三步：

pip install mailcap

然后继续运行就行。

Python 官方不会让生态断层，这点你完全可以放心。

顺便说说：现代代码应该怎么写？

趁着这次瘦身风波，很多人开始回头看看自己项目是不是还在用“古早风格”的写法。

比如你要解析 URL，以前可能写：

from urllib.parse import urlparse
r = urlparse("https://example.com/path?key=value")
print(r.query)

现在更推荐第三方库，功能更强：

from yarl import URL
url = URL("https://example.com/path?key=value")
print(url.query)

又比如异步服务器，以前有人用 asyncore，现在没人这么写：

import asyncio
asyncdefhandle(reader, writer):
    data = await reader.read(100)
    writer.write(data)
await writer.drain()
    writer.close()
asyncio.run(asyncio.start_server(handle, "0.0.0.0", 8000))

标准库越轻，现代工具越容易被使用。

这是不是“去电池（batteries included）时代的结束”？

不是。 Python 的哲学依然是：

“电池齐全，但不是把一堆过期电池全塞进来。”

瘦身后的标准库仍然非常强大：

• 文件与 IO
• 网络与并发
• 数据结构
• 类型系统
• 安全与哈希
• 正则
• 路径处理
• JSON / configparser / sqlite3
• 进程与线程
• 调试与日志

只是不会再把 20 年没人动、甚至没人想改的库留在里面。

这不是“削弱”，而是“现代化”。

会不会继续瘦？

很可能会。 Python 社区已经意识到 —— 不是所有库都适合永远留在标准库里。 未来可能会采用更灵活的策略：

• 核心模块永远内置
• 副工具库移到 PyPI
• 新模块先在 PyPI 测试，再考虑是否进标准库
• 不再“一进标准库就终身制”

Python 生态会变得更轻、更快、更健康。

作为一个一路看着 Python 2→3，再看到 typing、asyncio 成熟的人，我其实很能理解这次的方向。

标准库不是越大越好，更不是所有历史债务都得扛着。

能放下的，才是真轻。

如果你有正在维护的 Python 项目，也可以趁这个机会检查一下自己有没有依赖到这些“即将搬出去”的模块。