Python 3.0(又名 Python 3000)在三个月之前终于发布(2008 年12 月3 日)。自Python 之父Guido van Rossum 开始展望这个全新的、革命性的Python 版本,已经过去了近9 年光景。Python 3.0 打破了与旧有版本的向后兼容性。
在2007 年的一篇博文中,Guido 写到了 Python 3.0 的构思:
一直以来,除非要打破向后兼容性,否则很多缺陷和错误都无法修复。因此,Python 3000 将会作为第一个放弃向后兼容性的 Python 版本,目的就是要让 Python 向着最好的语言前进。
在稍后的一次访问中,Guido 叙述了接下来的事情:
大约在三年之后,我开始切实地投入进来,开始真正的设计它,时间大约就在我加入 Google 之后,对于 Python 我有了更多的时间。很长一段时间里,项目推进的很快,很多人因此而激动。我每年都在包括 PyCon 和 Euro Python 等很多会议上做演讲。在过去的 12 个月里,在开发者社区搞定了全部的细节并已经准备好发布了以后,虽然不是全部的投入,但是我花了很大一部分精力在上面,坐下来好好享受这个过程。
尽管 Python 3.0 打破了对 Python 2.x 的向后兼容性,但是其发布和 Python 2.6 的发布一道,为开发者提供了一种便捷和安全的方式,来实验各种新的特性。和之前的 Python 版本一样,Python 2.6 保持了对之前版本的全兼容,而且还包含了 Python 3.0 的新玩意(一些新特性需要通过“from __future__ import”来启用)。
Python 3.0 的新特性
Guido 说 Python 3.0 最出色的特性便是,“对 Unicode 的更好的支持,对各种’垃圾’进行清理”。而其中对 unicode 的全面支持则是变革的一个主要方面。Guido写到:
所有的文本都是 Unicode;然而,编码过的 Unicode 的会以二进制的数据来表示…… 基于这个哲学来修改的结果是,只使用 Unicode 的代码清爽了许多,编码和二进制数据都需要为此做出修改。这个修改是正面的,因为在 2.x 的世界里,大量的 bug 都是因为以编码的文本和未编码的文本混杂在一起而产生的。
尽管 Python 2.x 也支持 Unicode,但是它是通过一个(旧有的)str 类型和一个(新的)unicode 类型来实现的。在 Python 3.0 之中,所有的字符串都是 unicode 的(str 就是 unicode 字符串),并引入了一个叫做 bytes 的新类型来处理字节序列。
Python 3.0 的其他修改包括:
- Print 是一个函数 ─ print 语句已经被一个 print() 函数所替代。通过关键字参数来替代旧有 print 语句绝大多数的特殊语法(可以在 Python 2.6 中通过 from __future__ import print_function 来进行试验)。更多请参阅 PEP 3105 ─ 让 print 变为函数。
- 用迭代器来替代列表 ─ 一些知名的 API 将不再返回列表。而字典的 dict.iterkeys()、dict.itervalues() 和 dict.iteritems() 方法将会移除,而你可以使用.keys()、.values() 和.items(),它们会返回更轻量级的、类似于集合的容器对象,而不是返回一个列表来复制键值。这样做的优点是,可以直接在键和条目上进行集合操作,而不需要再复制一次。
- 整型数 ─ 移除了含糊的除法符号(’/’),而只返回浮点数。在以前的版本中,如果参数是 int 或者是 long 的话,就会返回相除后结果的向下取整(floor), 而如果参数是 float 或者是 complex 的话,那么就会返回相除后结果的一个恰当的近似。在 2.6 版本中可以通过 from __future__ import division 来启用这项特性。更多请参阅 PEP 238 ─ 修改除法操作符。
- 大量的语法修改
目前已经做了大量的工作,来使得向 3.0 版本的迁移尽可能的简单。很多新特性被反向移植到了 2.6 版本中,而且有一个新的命令行开关,可以打开对即将在 Python 3.0 中移除的特性的警告。你可以使用该开关来运行代码,来看看要将代码移植到 3.0 需要做多少工作。另外,有一个新工具叫做“ 2to3 ”,可以阅读 Python 2.x 的源代码,并执行一系列的修补器,来将代码转换为 Python 3.x 的代码。Guido 还补充到:
事实上,2to3 工具有一种模式,是可以不直接修改代码的,而默认情况下它是会的。你可以让它输出标准的 diff 来看看修改了什 么。如果需要的话,你可以逐个文件的去审校,然后再决定是否做出修改。“哦,没错,它这么做是对的。” 或者经过仔细审校以后,发现实际上这个工具犯了错误。你可以手工地修复这个文件,来重新进行修补。这样的话,工具依然会帮你节省大量的工作。这在 Python 2.6 到 3.0 的转换中是有先例的。
是应该选择 Python 2.6 还是 3.0 来进行开发?Guido这样说到:
… 决定选 3.0 抑或 2.6 是一个比较个人的选择。此时此刻,你不会为作为一个保守者而承担任何风险。2.6 依然会和 3.0 一样,会受到核心 Python 开发者的良好支持。同时,我们也不会稍稍降低 3.0 的质量和重要性。因此,如果你并没有外部需求,比如说依赖某个包或者第三方软件,而它们还没有被移植到 3.0,或者你并不是在一个大家都用 2.x 的环境中的话,那么就没有必要裹足不前了。
Python 及其社区最被人称道之处,就在于其做到了保守地前行,每个版本之间都做到了良好的向后兼容性。现在,Python 社区要做些与众不同的事──通过牺牲向后兼容性来开发一个更好的语言版本。Java 社区也一直有这样的想法,但是自从 1.2 版本(又名 Java 2)之后,“糟糕和丑陋之处”便不敢再去修正,怕的便是会破坏现有的代码。
查看英文原文: Python 3.0 Breaks with the Past
评论