P细数 Python 的「八宗罪」

本文作者有一群 geek 朋友，经常一起讨论技术话题，有时候也会谈到编程语言。「I hate Python」，作者表示。他对 Python 厌恶至极。即使有现成的 Python 代码可用，他也宁愿用 C 语言重写。为了系统地吐槽 Python，作者专门写了这篇博客，细数 Python 的「八宗罪」。

这个话题已经在 Hacker News 上引发了热烈的讨论(评论 400+)，感兴趣的读者可以去围观或参与一下。

Hacker News 讨论：https://news.ycombinator.com/item?id=18706174

1. 版本

如果要安装一个默认的 Linux 操作系统，那你很有可能需要安装多个版本的 Python：Python2、Python3 甚至是 3.5、3.7。原因在于：Python3 无法与 Python2 完全兼容。甚至一些用小数表示的版本(如 3.5、3.7)也明显缺乏向后的兼容性。

我完全赞成往编程语言中添加新的功能，我甚至不介意淘汰一些旧的版本。但 Python 却要分开安装。我的 Python 3.5 代码不适用于 Python 3.7 安装版本，除非我特意将其导入 3.7。很多 Linux 开发者都觉得导出太麻烦，因此安装 Ubuntu 的时候会一并安装 Python2 和 Python3——因为有的核心功能需要前者，而有的需要后者。

向后兼容性的缺乏和各自为政的版本通常会为其敲响丧钟。Commodore 创造了第一批家用电脑(比 IBM PC 和苹果都要早很多)。但 Commodore PET 不能与后续的 Commodore CBM 兼容。CBM 又不与 VIC-20、Commodore-64、Amiga 等兼容。因此，你要么选择花很多时间将代码从一个平台导到另一个，要么选择放弃这个平台。(Commodore 今天何在?早被用户抛弃凉凉了……)

类似地，Perl 也火过一阵。但 Perl3 与 Perl2 的很多代码也不兼容。社区骂声一片，于是一些好的代码导了出来，其他的则被抛弃了。Perl4 也是如此。等 Perl5 出来的时候，人们干脆改用另一种更稳定的编程语言。如今，只有一小部分人还在频繁使用 Perl 来维持之前的项目。但已经没有人用 Perl 创建新的大项目了。

同理，Python 的每个版本也都存在谷仓效应。之前的版本还要留着，最终造成手里有一堆旧的无用 Python 代码，因为大家都不想花时间将其移到最新版上。据我所知，没有人为 Python2 创建新代码了，但我们还留着它，因为没有人想将所需代码移到 Python3.x 中。Python 2.7、3.5、3.6、3.7 的文档都还在 Python 官网上积极维护着，因为他们无法下决心弃用之前的代码。Python 就像一种僵尸编程语言——已经死掉的部分还在以行尸走肉的方式存在着。

2. 安装

很多软件包都可以帮你轻松地运行 apt、yum、rpm 或其他一些安装库，并获得最新版本的代码。但 Python 并非如此。如果用「apt-get install python」安装，你都不知道自己安的是哪个版本，它可能也无法与你所需的所有代码兼容。

因此，你要安装你需要的那版 Python。我的其中一个项目用到 Python，但必须用 Python3.5。所以最后，我的电脑安装了 Python2、Python2.6、Python3 及 Python3.5。其中两个来自操作系统，一个用于项目，另外一个服务于出于其他原因安装的无关软件。虽然都是 Python，但此 Python 非彼 Python。

如果你想安装 Python 包，你应该使用「pip」(Pip Installs Packages)。但由于系统上有一堆 Python，你要注意使用正确版本的 pip。否则，「pip」可能运行「pip2」，而不是你需要的「pip3.7」。(如果名称不存在，你需要为 pip3.7 指定明确的真实路径)

一位队友建议我配置自己的环境，这样的话每种软件都可以使用 Python3.5 的 base 环境。在我需要用 Python3.6 开展另一个项目之前，这种做法是非常行得通的，但是需要 Python 3.6 就得创建另外一个环境。两个项目，两版 Python，一点都不会混，真的(用生命在假笑)。

pip 安装程序将文件放置在用户的本地目录。安装系统级的库时不用 pip。Gawd 不允许你在运行「sudo pip」时出错，因为那会毁了你的整个电脑!运行 sudo 可能会使一些软件包在系统级别安装，有些是为错误版本的 Python 安装的，而你的主目录中的一些文件可能最终归 root 所有，因此未来的非 sudo pip 安装可能会因权限问题而失败。不要这样做。

这些 pip 模块由谁来维护呢?当然是社区。也就是说，没有明确的所有者，也没有强制性的来源链或责任链。今年早些时候，PyPI 的一个版本中发现了一个窃取 SSH 凭证的后门。这也是意料之中。(出于同样的原因，我不用 Node.js 和 npm;我不信任他们的社区项目。)

3. 句法

我非常主张代码的可读性要强。乍一看，Python 的可读性似乎不错。但当你开始创建大型代码库的时候你就不会这么想了。