『Python』为什么迁移至 Python 3 这么难？ |设计|跳槽那些事儿|软件|

2020 年 1 月 1 日， Python 2 的生命周期正式截止， Python 核心开发人员也宣布即将不再提供该版本的安全更新，并建议用户尽快迁移至 Python 3 。然而问题也在此时出现了，不论 Python 3 有多少优点，迁移的过程对于用户来说都极其痛苦，但是如果不这么做的话，又会有其他问题出现。对此，开发者只剩一声长叹，难啊！
迁移至 Python 3 ，用户怨声载道 2020 年 3 月 4 日，一位用户在 Twitter 上吐槽：

本文插图
他的大概意思是：“每个人都坚持要摆脱 Python 2 ，但这样的做法却将我们拥有的所有功能完善且有用的 Python 2 代码从资产变成负债。 ”
随后他又举例说：

本文插图
“自 2011 年用 Python 2 编写以来，我的 milter 实现一直是完全稳定的。现在，我不得不破坏它的稳定性，因为 Python 2 没法用了。 ”
有同样感受的人不只是他一个，尤其是那些大公司的开发人员。
2013 年，Facebook 计划将代码迁移至 Python 3，但是从产生这个想法到真正交付，一共花费了四年的时间，代码迁移仅仅是难题的开始，更重要的是让自己的员工使用并适应 Python 3；另有 LinkedIn 进行的“旷日持久战” ， 550 个代码存储库（库、应用程序和服务）要迁移、上百万行的代码要处理，还有内部用于持续集成 / 持续交付（CI/CD）框架、命令行接口以及部署和数据科学工具，这种散乱的非整体式环境用 Warsaw 的话来说“包括数百种独立的微服务和工具，外加几十个支持库。
如此浩瀚的工程，花费的时间、精力都是巨大的，参与其中的人怨声载道，甚至有人将其称之为“噩梦般的工作” 。然而当庞大的迁移终于完成，新的问题又出现了。
跨平台的分布式版本控制软件 Mercurial 就是 Python 编写的，所以对于向 Python 3 的迁移， Mercurial 也是非常的积极。在经历了同样大规模的迁移后，问题暴露了出来，负责 Mercurial 运维工作的工程师 Gregory Szorc 在博客上进行了一番吐槽：
简而言之，我将 Mercurial 和其他项目移植到 Python 3 的经验极大地破坏了我对 Python 的理解。从语言到热情的社区，我一直以来都对 Python 充满爱，但我仍在努力理解 Python 如何通过选择他们所做的过渡计划来设法给社区带来如此多的困难。
…
Python 3.0 于 2008 年 12 月 3 日发布，社区花了十年的时间来接受它。这应该被普遍认为是失败的。
…
【『Python』为什么迁移至 Python 3 这么难？】我真的对 Python 很不满意。移植到 Python 3 所需的工作量惊人。对于 Mercurial 而言， Python 3 引入了很多问题，但并不能解决很多问题。我们在泥泞中摸爬滚打了好几年，直到最终陷入比我们开始时更糟的状态。我敢肯定，几年后它将变得更好。但是在此之前，我们要经历 5 年以上的过渡期。官方宣称 Python 3 过渡会对项目造成破坏和干扰，这是一种太轻描淡写的说法。
问题出在哪里？ Python 3 的迁移为什么如此困难？回答这个问题之前，我们先简单了解一下它诞生的背景。
自 2008 年发布以来， Python 2.0 已经走过了十多个年头。它的最后一次重大更新 ——Python 2.7 是在 2010 年。
虽然 Python 2.x 是一个还不错的版本，但同时也带来了相当大的历史包袱，例如，它有两种整数类型；存在恼人的 Unicode 编码问题；它混淆了懒惰和渴望的功能工具；它有一个标准的库，但加载内存非常庞大；它自诩的强类型，却有偶尔令人啼笑皆非的运算结果 None < 3 < “2” 。总的来说，它的一些“阴暗角落“ ，包含了 Python 1 时代太多的历史包袱。