作者丨陈思
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
由于修正这样一些问题或许会损坏现有代码，而简直一切为 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 的安排供给了怎么完结跨代兼容性的归纳攻略，以下是其主张的摘要：
抛弃对 Python 2.6 和更早版别的支撑，由于从 Python 2.7 搬迁要简单得多，而且假如有必要运转 Python 2.6，请考虑运用 six library 来与 Python 3 兼容。
保证 setup.py 文件正确指定了代码库支撑的 Python 版别，而且该文件至少包括 Programming Language :: Python :: 2 :: 仅作为 trove 分类器。
测验套件应至少具有 80％的代码覆盖率，即在测验进程中履行多少源代码的称号。假如不了解代码覆盖率，请运用 coverage.py 供给的东西。
阅览 Python 的“新增功用”文档和免费的“ 移植到 Python 3”手册，了解 Python 2 和 Python 3 之间的差异。
运用 Futurize 或 Modernize 使 Python 2 代码与 Python 3 兼容，请保证阅览文档，以便处理这些无法处理的问题。
保证习惯在 Python 2 和 3 之间处理整数除法的更改。例如，在 Python 2 中 9/2 = 4，而在 Python 3 中 9/2 = 4.5。假如可以在代码中运用“future import”除法和“//”运算符进行整数除法，那么代码现已与 Python 3 兼容。
Python 3 更改了可以与 str 类型一同运用的数据，以使文本和二进制数据之间的差异愈加明晰。不幸的是，关于一同处理文本和二进制数据的代码，有必要履行以下进程以保证代码契合规范要求：https://docs.python.org/3/howto/pyporting.html#text-versus-binary-data
当运转的代码因运转的版别不同而体现不一同，最好查看 Python 3 支撑的特定功用是否可以运转，而不是查看 sys.version_info [0] 是否等于 3。
为了协助对齐用 Python 3 编写的任何新代码并保证其兼容性，请在创立的任何新模块的顶部运用以下句子：from future import absolute_import, from future import division, 以及 from future import print_function。
运用 caniusepython3 供给的东西，查看哪些软件依靠项会阻挠支撑 Python 3 。
搬迁代码后，请在 setup.py 文件中更新分类器，使其包括 Programming Language :: Python :: 3，以标明代码支撑 Python 2 和 3。
经过运用 tox 主动化测验并将此设置与继续集成体系进行集成，以保证代码与 Python 2 和 3 坚持兼容。
别的，为了将 Python 2 搬迁到 Python 3 代码，NCSC 还主张运用 2to3 应用程序，该应用程序将测验主动履行该进程。
总而言之，尽管很费事，可是为了坚持功用的先进性，企业或个人开发者仍是不得不挑选搬迁到 Python 3。假如想防止搬迁进程呈现一些显着的反常问题，可以参阅一些大公司的搬迁状况，这里有一些事例可供参阅，期望有时机可以帮到广阔开发者：
上文说到的 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
点个在看少个 bug
