『云头条』Python3 迁移怨声载道( 二 )

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 。 ”
【『云头条』Python3 迁移怨声载道】“相反拖了十多年，因为实际上我们需要编写与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的一些新功能。