自从 Python 1.5.2（一个长期以来一直稳定且可靠的版本）迈入 “黄金时代” 以来，Python 增加了许多语法特性以及内置函数和类型。这些改进单独地看都是合理的调整，但是作为一个整体，它们使 Python 变得更加复杂，不再是有经验的程序员 “花上一个下午” 就能够掌握的语言了；另外，一些修改在带来好处的同时也有缺陷。

    在本文中，我要讨论在最近几个 Python 版本中增加的不那么引人注目的特性，我将分析哪些改进具有真正的价值，哪些特性只是不必要地增加了复杂性。我希望向所有并非一直使用 Python 的程序员指出真正具有价值的东西。这包括使用其他语言的程序员以及只将编程当做副业的科学家。当遇到一些难题时，我会提供解决方案。

不可比较的麻烦

    在 Python 2.0 和 Python 2.1 之间，发生了一些奇怪的变化。以前可以比较的对象在进行比较时却引发了异常。具体地说，复数无法与其他数字进行比较了，包括其他复数以及整数、浮点数和长整数。实际上，在此之前，比较 Unicode 字符串和文本字符串时就可能会遇到这个问题，但那只发生在一些极端情况下。

    我认为，这些修改很怪异，没有必要。在 1.5.2 的黄金时代，无论比较什么对象，不等操作符总会返回一个结果。当然，结果不一定是有意义的 —— 比如字符串和浮点数的比较就没有意义。但是，至少我们总会得到一个一致的结果。

    出现这些修改之后，一些 Python 支持者认为不允许对不同类型的对象进行不等比较是件好事，只有定义了定制的比较函数之后，才能进行这种比较。我觉得，在处理定制类和多重继承时，编写定制的比较函数实际上很需要技巧。另外，不能在浮点数、整数和长整数（比如 decimal）之间进行比较是非常不方便的。但是，或许可以定义一个合理的规则。

    但是，无论定义什么样的规则，它都与 Python 过去的做法有非常大的差异。现在的情况是比较行为无规律可循，即使知道比较的对象的类型，也无法确定它们是否是可比较的（而且不等性既非可传递也非封闭式）：

清单 1. 比较是否成功取决于类型和值
>>> map(type, (u1, s1, s2))
[<type 'unicode'>, <type 'str'>, <type 'str'>]
>>> u1 < s1
True
>>> s1 < s2
True
>>> u1 < s2
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf0 in position 0:
    ordinal not in range(128)
>>> map(type, (n, j, u1))
[<type 'int'>, <type 'complex'>, <type 'unicode'>]
>>> n < u1
True
>>> j < u1
True
>>> n < j
      TypeError: no ordering relation is defined for complex numbers

[1] [2] [3] [4] [5] 下一页