Python之父差点砍掉import！认为模块系统是最大败笔？！

前言

大家好，我是倔强青铜三 。欢迎关注我，微信公众号：倔强青铜三。欢迎点赞、收藏、关注，一键三连！！！

"如果当年我把import扔进垃圾桶，今天就不会有pip、也不会有PyPI。"

2003 年 PyCon 的闭门圆桌，Guido 的这句话让全场瞬间安静。
Python 1.x的模块系统 被无数人视作开天辟地的创举，可在创建者眼里，它曾是一场险些失控的灾难------嵌套包、相对导入、循环引用的噩梦，早在 1994 年就埋下了祸根。

1991 年的 import foo 只有两行核心代码：

看似优雅，却留下了三个无法回头的漏洞：

到 Python 1.2 发布时，标准库已有 78 个 .py 文件，平铺命名空间的冲突率首次突破 30% 。

Guido 在邮件列表写下：

"也许我们根本不该把模块暴露成全局单例。"

1994 年 5 月，社区爆发"包大爆炸 "事件。

第三方开发者把 sound、image、crypto 全部放入顶级名字，官方库一夜之间被挤到第二页 。

Guido 提交了史上最具争议的 PEP------"PEP 0：废除 import" 。

核心提案只有一句：

"用显式加载器 load('path/to/module.py') 取代魔法导入。"

反对者在两周内回邮 400+ 封，核心论点直击要害：

失去"一次编写，到处运行"的易用性。
破坏向后兼容，等于让 Python 1.x 全体用户重写代码。
最终投票结果：反对 73%，支持 27% 。
import 被保留，但留下了妥协补丁：
1995 年的 Python 1.4 引入包目录 __init__.py，首次允许嵌套命名空间。
搜索路径改为可配置的 site-packages，把第三方与标准库隔离。

包目录解决了命名冲突，却带来了新的地狱 ------相对导入 。

1996 年的 Python 1.5 允许 from .foo import bar，初衷是"让子包自给自足"。

然而早期实现把相对路径写进了编译期常量：

c 复制代码

/* import.c */
static char *relative_base = NULL; /* 线程不安全 */

多线程下，两个包同时触发相对导入，relative_base 会被覆盖成野指针，解释器直接段错误。

直到 2000 年的 Python 2.0 才用绝对导入 修复，却把语法级歧义留了下来：

python 复制代码

from foo import bar   # 是顶级 foo，还是当前包的 foo？

为了向后兼容，Python 2 默认优先相对导入 ，导致整整十年里，"绝对导入"必须写成 __future__ 魔法：

python 复制代码

from __future__ import absolute_import

模块系统的"败笔"反而催生了生态奇迹 。

1998 年，Distutils 的作者 Greg Ward 利用import 钩子 （PEP 302 前身）把 .egg 文件塞进 sys.meta_path，首次实现"复制即安装 "。

2005 年 setuptools 把钩子升级为 easy_install，2008 年 pip 沿用同一机制，最终让 PyPI 成为全球最大的开源仓库。

如果没有 1.x 时代留下的"过度灵活"，Python 不可能在 2010 年前就拥有 10 万+ 第三方包。

2020 年，Python 3.9 引入"命名空间包 "，彻底废除 __init__.py，看似最终解决了目录层级问题。

但核心开发者 Brett Cannon 在博客中坦言：

"我们每修复一次 import，就多背一条 1.x 的兼容包袱。"

从 1991 年的两行代码到 2024 年的 2000 行 C 实现，Python 的模块系统像一棵老树：根是败笔，枝桠却撑起了整片森林 。

下次你在 PyPI 一键 pip install 时，不妨想想------

如果当年 Guido 真把 import 扔进垃圾桶，今天的 Python 还会是你认识的模样吗？

最后感谢阅读！欢迎关注我，微信公众号：倔强青铜三。欢迎点赞、收藏、关注，一键三连！！！