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所需的工作量惊人。对于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 时代太多的历史包袱。

由于修复这些问题可能会破坏现有代码，而几乎所有为 2.0 编写的代码仍可在 2.7 上运行，Python 3 应运而生。

设计之初，Python 3 的预期是用户会直接转移到新版本，从而放弃使用 Python 2 。然而在一开始，人们有很多理由不采用Python 3：最主要的原因是，它并没有与Python 2兼容。同时，大多数的库希望同时在 Python 2 和 Python 3 上运行，这在一开始很难运作，并且由于缺乏支持工具，移植代码的工作十分艰难。

转折点发生在大约2016年左右的Python 3.5发行版中，该版本增加了矩阵乘法、引入了asyncio、对OrderedDict的速度进行了提升以及实现了类型提示，这些提示为Python带来了一些类似于静态语言的功能。

更高版本包含更多功能，例如Pathlib库和 f 字符串操作。通过这些更改，人们使用的许多库（例如用于机器学习的scikit-learn ）开始向Python 3迁移。

除了Python 3本身存在的一些技术问题，用户不愿意迁移的主要原因还有这样几点：

安全问题。具有讽刺意味的是，用户会认为不进行升级会带来更大的风险，但是在大型组织或机构中，不允许员工自己升级Python：管理员或安全团队会向他们推送更新。在某些情况下，也不允许下载PIP。如果Python 2是安全团队同意的默认设置，那么它可能需要做出巨大的努力才能说服人们将其切换到3，尤其是在受到严格监管（例如医疗保健或金融）和政府的环境中。

使用惯性。尽管许多版本的Linux中（例如RHEL），都同时兼容Python 2与Python 3，但这不是默认的选项，因此用户在2和3之间切换时，经常发现一些错误，尤其是指向系统版本的指针，例如，在Debian上使用Python。

如何避免迁移出现问题？

如何迁移到Python 3？每家公司的做法可能有所不同，所以在此之前，不如先看看官方给出的建议。

Python软件基金会已经为需要同时运行Python 2和3的组织提供了如何实现跨代兼容性的综合指南，以下是其建议的摘要：

1.放弃对Python 2.6和更早版本的支持，因为从Python 2.7迁移要容易得多，并且如果必须运行Python 2.6，请考虑使用 six library 来与Python 3兼容。

2.确保setup.py文件正确指定了代码库支持的Python版本，并且该文件至少包括Programming Language :: Python :: 2 ::仅作为trove分类器。

3.测试套件应至少具有80％的代码覆盖率，即在测试过程中执行多少源代码的名称。如果不了解代码覆盖率，请使用coverage.py提供的工具。

4.阅读Python的“新增功能”文档和免费的“ 移植到Python 3”手册，了解Python 2和Python 3之间的区别。

5.使用Futurize或Modernize使Python 2代码与Python 3兼容，请确保阅读文档，以便解决这些无法处理的问题。

6.确保适应在Python 2和3之间处理整数除法的更改。例如，在Python 2 中 9/2 = 4，而在Python 3 中 9/2 = 4.5。如果可以在代码中使用“future import”除法和“//”运算符进行整数除法，那么代码已经与Python 3兼容。

7.Python 3更改了可以与str类型一起使用的数据，以使文本和二进制数据之间的区别更加清晰。不幸的是，对于同时处理文本和二进制数据的代码，必须执行以下步骤以确保代码符合要求：
https://docs.python.org/3/howto/pyporting.html#text-versus-binary-data

8.当运行的代码因运行的版本不同而表现不同时，最好检查Python 3支持的特定功能是否能够运行，而不是检查sys.version_info [0]是否等于3。

9.为了帮助对齐用Python 3编写的任何新代码并确保其兼容性，请在创建的任何新模块的顶部使用以下语句：from future import absolute_import, from future import division, 以及 from future import print_function。

10.使用 caniusepython3 提供的工具，检查哪些软件依赖项会阻止支持Python 3 。

11.迁移代码后，请在setup.py文件中更新分类器，使其包含Programming Language :: Python :: 3，以表明代码支持Python 2和3。

12.通过使用tox自动化测试并将此设置与持续集成系统进行集成，以确保代码与Python 2和3保持兼容。

另外，为了将Python 2迁移到Python 3代码，NCSC还建议使用2to3应用程序，该应用程序将尝试自动执行该过程。

总而言之，虽然很麻烦，但是为了保持功能的先进性，企业或个人开发者还是不得不选择迁移到Python 3。如果想避免迁移过程出现问题，可以参考一些大公司的迁移情况，这里有一些案例可供参考，希望可以帮到广大开发者：

Facebook的Python 3迁移：
https://mp.weixin.qq.com/s/l9lw1xIjr73XZTWp27-l2A
上文提到的Mercurial的Python 3迁移：
https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflections-on-python-3/
Dropbox的Python 3迁移：
https://dropbox.tech/application/how-we-rolled-out-one-of-the-largest-python-3-migrations-ever

创作场景

为什么迁移至 Python 3 这么难？