点击上方“编程派”，选择设为“设为星标”

优质文章，第一时间送达！

今年1月1日，Python 2代码库被冻结。从那天起，不再有Python 2进一步的向后移植（backport），实际上使这种语言及运行时环境成了过时的技术。核心开发人员Nick Coghlan在FAQ中解释道，因而结束了“核心开发团队为参考解释器同时维护Python 2和3长达约13年”的局面。

Python 2的最终版现正通过beta测试版和发行候选版阶段，预计最后一个生产级版本Python 2.7.18会在2020年4月推出。

虽然Python社区中的大多数人一致认为Python需要大刀阔斧的改动——尤其是由于迫切需要的、早就该有的统一码（Unicode）支持。但是Python 2代码运行得好好的许多人颇感沮丧。有关这种迁移的真实故事在网上比比皆是，领导迁移工作的开发人员更是有话要说。

迁移故事

Chris Siebenmann上周巧妙地总结了一些挫折感，他的Twitter个人资料显示他是一名“过于投入的系统管理员”。

Siebenmann在一篇博文中写道“没必要维护就可以运行的实用代码是一种资产；它就在那里，处理有价值的任务，不需要你做任何工作。为了不破坏系统（而不是添加任何功能）而必须做大量工作的代码是一种包袱；你得做一番工作，还引入了风险，却一无所获。”

但是他的处境没有博得云/ AI架构师Phil Rhodes的多少同情，后者创办了Fogbeam Labs，这家公司生产开源企业软件，他在Hacker News网站上提出了相左的观点。“大约12年来，人们始终知道需要开始迁离Python 2。如果你现在因Python 2即将消失而感到恐慌，很难不问‘你之前在等什么？’”

大公司同样面临迁移方面的挑战。LinkedIn的高级软件工程师Barry Warsaw还是自上世纪90年代中期以来的Python指导委员会成员和Python核心开发人员，他在博文中描述了“在完成大概两个季度的规划和两个季度的执行之后”，LinkedIn为完成代码库的迁移开展了旷日持久的“横跨多个季度的工作”。

开发团队先在图上列出了诸依赖项以确定工作优先级——列出了75个“基础性”存储库，然后创建了内部库的“双语”版本（可以使用Python 2或Python 3）。

Warsaw提到多个团队和部门的工作时写道：“这项工作需要共迁移约550个代码存储库（库、应用程序和服务）。”除了面向用户的服务外，LinkedIn还在内部使用Python用于持续集成/持续交付（CI/CD）框架、命令行接口以及部署和数据科学工具，这种散乱的非整体式环境用Warsaw的话来说“包括数百种独立的微服务和工具，外加几十个支持库，它们都归分管不同存储库的独立团队拥有。”

但是并非所有人都感到很高心。1月份，开发人员Wayne Rowcliffe在Hacker News上发帖称其工作场所终于“快要完成迁移到Python 3的工作”。

“这项工作的最终结果是，上周我花了很大一部分时间来审核有70000行代码变更的合并请求（pull request），这是去年秋天进来的大约1万行变更请求中的最后一个合并请求。这一切都是我一位同事的杰作，他那无人羡慕的任务是梳理我们的整个代码库，以确定‘这是统一码。这是字节。这是我们需要编码/解码的API边界’等等。”

“那是噩梦般的工作，很高兴我们捱过来了。”

他在后来的评论中将策略归结为9个字。“我们运行了代码检查工具和测试套件，直到一切都过关。只是这时你面临100万行代码，要花不少的时间。”

Mercurial的见解

另一番批评来自旧金山的开发人员Gregory Szorc，他是Mercurial版本控制工具的维护者。Mercurial与Python社区关系密切——Python一直使用Mercurial作为其存储库，但在2016年改用了Git。不过Szorc在一篇博文中描述了Mercurial在2019年11月5日努力获得Python 3支持时所得到的体会，他对来自Python语言内部的瓶颈提出了一番批评。

他写道：“该项目在Python 3移植版方面起步很晚，主要归因于Python 2.4和2.5兼容性阻碍了我们。我们放弃了对Python 2.6的支持。这极大地降低了支持Python 3的复杂性，因为Python 2.7中有大量的功能使得更容易既面向Python 2又面向Python 3，而现在我们的手没有被绑住，可以使用它。”

但令人惊讶的是，Szorc称，甚至Python 3版本之间存在一些变化（“我们不得不糊上墙纸”），这在2019年中期的“冲刺阶段”中显露出来。虽然Python 3.7的错误最少，但是“我们不得不花另外的精力使Python 3.5和3.6以及3.7正常运行。Python 3.8也一样。”

很快，Mercurial迎来了迁移的重大日子。在持续集成系统（使用亚马逊的AWS DynamoDB、S3和EC2竞价型实例用于执行作业）上，Szorc开始在Linux上测试Python版本3.5、3.6、3.7和3.8（并在Windows上测试Python 3.7）。但是虽然通过了所有测试，“我认为交付只是漫长过程中的一块里程碑——大概是最重要的里程碑。仍有很多工作要做……我们的用户可能多年后会在Python 3上发现各种bug。”

Windows上仍然存在“少数的已知问题”。

这次经历让Szorc感到一些不快。Szorc写道：“虽然过去我喜爱Python——从这种语言到受人欢迎的社区，还是搞不明白Python如何因当初选择了迁移计划而给整个社区带来如此多的困难和麻烦。我认为Python的选择是一个反面典例，表明了在管理大型项目或生态系统时不该做什么。如果花时间来了解和反思Python的失误，其他广泛部署系统的维护者将受益匪浅……”

“Python 3的最初方法反映了许多开发人员和项目所犯的愚蠢行为：尝试重写而不是执行渐进式演变。对于既有的项目，大规模重写常常效果不佳。而Python 3也不例外。”

其他见解

Szorc的博文出现在Hacker News上后吸引了400多人点赞，另有339条留言，包括一位持不同意见的纽约市软件工程师。“我参与了多年来以同样的代码库支持python2和python3的多个重要的库和框架……而其实并不是这样的……是的，你几乎不得不等待python-3.4即将发布、等待python-2.6基本上退役，改而使用python-2.7。随后从2014年初开始，使干净的代码库与python-2.7和python-3.4 +兼容显得非常简单。”

夏威夷大学的一名学生认为，人们对一款名为2to3的迁移程序寄予太高的期望，该程序试图提供一个自动代码翻译器。有人在回复时抱怨道：“Python 2到3的迁移计划根本行不通。他们以为所有人会大规模运行2to3，然后几年后我们所有人都会切换到3。”

“相反拖了十多年，因为实际上我们需要编写与Python 2和3都兼容的代码……直到足够的代码使用3、放弃对2的支持。”

而一些人质疑这项工作所取得的成果。华盛顿的电气工程师Brian Davis自称是“老派的Web开发人员”，他在将“许多”小项目转换到Python 2之后分享了其想法。“字符串处理方面的变化把我难住了，相对导入方面的变化也颇费一番思量。但是最挫折的是这个棘手的问题：我干嘛这么做？”

另外见解

从一些方面来看，Python 2没有真正消失。比如有Tauthon，Python 2.7.17解释器的这个向后兼容分支有新的语法，以及从Python 3.x向后移植的库。Tauthon可以运行Python 2.7代码和C扩展以及来自Python 3.x的一些新功能。

除了Python Package Index中所列的第三方开源软件包外，开发工具公司ActiveState还为Python 2及其标准库提供商业支持。

不过，大多数开发人员现置身于Python 3时代。但到头来，也许正是默默付出的艰辛工作400多位匿名人士点赞Szorc撰写的那篇博文。他的博文写道：“移植到Python 3所需的工作量惊人。对于Mercurial来说，Python 3带来了一大堆问题，好多问题其实解决不了。”

他写道：“称Python 3迁移项目具有破坏性、让人分心并不过分。作为项目维护者，很自然地会问如果不强迫我们做这件次要的事情，我们本可以取得什么样的成就。”

回复下方「关键词」，获取优质资源回复关键词「 pybook03」，立即获取主页君与小伙伴一起翻译的《Think Python 2e》电子版
回复关键词「入门资料」，立即获取主页君整理的 10 本 Python 入门书的电子版
回复关键词「m」，立即获取Python精选优质文章合集
回复关键词「book 数字」，将数字替换成 0 及以上数字，有惊喜好礼哦~
题图：pexels，CC0 授权。好文章，我在看