点击上方“编程派”,选择设为“设为星标”
优质文章,第一时间送达!
今年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 授权。
好文章,我在看