科学家们还会不会迁移到Python3?
自Python3面世刚满4年,在Python用户群体中对它的看法仍然各种各样。对这些看法不了解的朋友们介绍一下背景:尽管Python3是一个相对Python2改进巨大的更新版本(具体的改进可查看这里),它有一个致命的劣势,未保持向后兼容:尽管Python3.x(通常简称为Py3k)保留了老版本Python的内涵,仍然有很少一部分在Python2.x下有效的代码无法在Python3.x下解析。 退一步说,破坏向后兼容『富有争议的』。我认为这是实用主义者 -- 那些觉得Python是一个非常有用的工具,如无必要就别乱改 -- 与完美主义者 -- 那些把Python语言当成是一个活的会呼吸的实体,它应该发展成相对它自己来说更好,更Pythonic的版本。 Python科学计算社区主要偏向于实用主义者的阵营。部分原因是因为科学固有的实用主义(在一个要么发论文要么没得发的世界里,这些Python用户并不常有时间考虑他们使用的工具是否完美),另一部分原因来自于公共机构上的压力,我会在下文叙述。但是不管这些原因,Python科学计算社区迁移到Py3k的动作异常缓慢。作为Python科学计算生态系统的核心的Numpy,第一个支持Py3k的1.5版本发布于2010年,在Py3k面世2年后才完成。Scipy紧跟其后在2011年3月发布了支持Py3k的0.9版。IPython,2011年12月发布0.12版。核心科学计算的软件包中最后的落跑者matplotlib,刚刚在2012年11月的1.2版中支持了Py3k。 让一个随意的旁观者点评这些进展,他可能会认为这个迁移已经基本完成:科学家可以放心地使用Py3k而不用担心常用工具不支持。但事实上,迁移还遥遥无期。Numpy和Scipy的开发团队刚刚在上个月决定放弃支持Python2.4(它的第一版在2005年3月发布)。即便如此,他们仍在讨论最后一个支持2.4的版本该如何做才能保证让那些Python 2.4用户在未来长期稳定使用(很多公共机构使用的发行版,例如RedHat Linux,更新自带Python老鼻子地慢了)。以相同的速度推断,我们可以预计对Python 2.7(第一个版本在2010年7月发布)的支持可能在2018年中才结束。但是这可能仅仅是个过于简单的预期,原因我下面再解释。整个迁移过程中有一个非常致命的部分我从来没听其他人提起过:我认为限制Python3被科学计算社区广泛接纳的主要原因是缺少一个完成度较高的3到2的转换工具。 接下来我解释这个观点。

不同种类的用户

在开始评估『科学计算社区需要做什么以完成向Python3迁移』这个问题前,我需要将这个社区的用户群分为3个大类。这些类别并不互斥(我正好3个类别都算),但是这样分类可以帮助我们思考各人群决定迁移到Py3k时背后无形的手。分类如下: 独立科学家 指那些在自己独立项目上使用Python的研究人员:对他们的数据进行统计分析,数据生成,以及编写胶水代码将老旧的代码组合起来 协作科学家 指那些身处大型科研队伍中或在一个公共的Python代码上合作开发的研究人员。我个人比较熟悉情况的例子是LSST合作组:LSST系列软件已经由一个大团队持续开发了数年,主要用C++和Python2.x进行开发 Python科学计算软件开发人员指那些处于上述组别的同时,进一步参与了Python科学计算生态系统相关软件包开发的科学家。这些软件不仅限于前文已经提到的NumPy/SciPy/IPython/Matplotlib等,还包括了处于外延的用于特定领域和应用场景的软件包 这3组人群的需求和制约各不相同,影响了他们迁移到Py3k上的难度:

独立科学家

这个类别的人群可能是3个类别中自由度最大的,因此可能也是果树上最易采摘的水果。因为没有沉重的历史代码包袱,他们可以随时决定拥抱Py3k。我在华盛顿大学读研究生的时候亲眼见证过一个相似的迁移过程:在我的博士开始阶段,院里几乎每个人都在用一门私有语言IDL。但是当我毕业时,大约一半的人主用语言已经转成了Python。 虽然我非常想把这个迁移的部分功劳归于我(我一直孜孜不倦地推销Python相对IDL的好处),但事实上这个迁移更主要的原因是Python被几个重要的天文学合作组采纳,以及将Python推荐给学生的几个新晋教授带来的影响。

协作科学家

上面也提到了,即使是最独立的科学家也不可能与他们的同事完全隔绝,团队中有影响力的成员使用的工具会影响到其个人项目上的工具选择。但忽略掉这个同行压力,身处大型协作团队中的科学家仍受制于在现有代码上投入的不计其数的时间。如果这个代码是Python2.x的,那么迁移到Python3就不仅仅是『更好的unicode和iterator支持』这样的理由能推动的了。 正因如此,我已经看到过很多人对Python核心开发团队决定发布一个向后不兼容版本时表示怀疑(甚至是愤怒)。在一次交谈中,一个我认识的普林斯顿的天文学家(除了瞩目的学术成就外,他也因为这个观点出名)将Py3k的发布是『完全愚蠢的』,并且说天文学界永远不会接受Python3。我自己的看法偏向于乐观,但是这个观点表现了科学计算社区内部对Py3k的看法。

Python科学计算软件开发人员

这些花时间为社区做出贡献的科学家们的情况比较特殊。他们对Python的看法相对于他们的同行来说稍微不那么『实用』一点,并且有时有愚蠢的习惯(例如用自己的闲暇时间写标题带Python的日志--作者在吐槽自己么…)。他们通常习惯于在自己用的所有电脑上安装多个Python版本,因此他们在不同时间身处不同研究团队时受研究团队的Python偏好影响更小。即便如此,身处这个分类的人可能也没有在用Python3.x。这可能是因为Matplotlib -- 一个重要的科学计算工具 -- 才刚支持Python3,但是我觉得不仅仅是这个原因。比如说我,在matplotlib 1.2出来的时候也没有立即升级到Python3,相信很多人和我一样也没因为这个新版本而迁移到Python3。 这个问题的核心在于:即使NumPy/SciPy/IPython/Matplotlib已经兼容Py3k,软件的开发仍然是在Python2.x下进行的。Py3k的兼容是通过2to3及其他工具完成的。这就是问题的所在:如果没有其他强制性原因,只要开发还是在Python2.x上进行,这些开发者就不会将他们自己的项目迁移到Py3k。

展望

探究三个分类各自的需求和动力,得出的结论是Py3k在科学计算领域的作为很有限。独立科学家没有迁移的压力,协作科学家过于固执所以不太可能迁移。即使是那些积极参与Numpy和Scipy开发的科学家也不能在开发时用Python3,所以没有大的动力去迁移。科学计算软件开发人员可能机会最大,因为他们有催化社区其他人员的潜力:他们是写线上文档和教程的人,他们在SciPyPyDataPyCon以及其他与他们领域相关的会议上发表演讲,他们影响了培训机构里Python课程的设置如Software Carpentry。总之,将Python科学计算社区迁移到Python3的唯一希望就寄托在这些科学计算软件开发人员身上了。将Numpy/Scipy/IPython/Matplotlib的开发环境和其他核心软件包迁移到Python3,社区的其他人员就会逐步跟上来了。 问题是,目前这不可能。实际上,Python2.x将继续被Numpy/Scipy支持至少10年。如果如果Numpy/Scipy的开发环境要转移到Py3k,我们需要一个开发成熟的3-to-2转换工具,将3.x代码转换到2.5及以上版本。有这样的工具,开发环境就可以继续在Py3k下进行同时保证2.x的兼容性。雏形已经有了,但是还不如2to3工具那么成熟,也没有2to3工具实现起来容易。它的不成熟度是可以理解的:将新的转换成旧的远不如将旧的转换成新的那么容易。但是从我勾勒的几个理由来看,这个工具将变得异常重要。 所以这是我对所有Python理想主义者的挑战:如果你希望科学计算社区完整地接受Python3,请将开发全功能3to2工具的优先级提高,并开始尽力让Numpy迁移开发环境到Py3k。**我自己可能会这么做,但是我更多的是一个实用主义者:Python2.7在我自己的研究上完全够用了。我打个赌:如果这个工具有一天完成了,社区里其余的人会很快跟进。
yegle