InfoQ▲Python 3 这么难？，为什么迁移至 2020年1月1日

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

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

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