深入 PEAK 的新特性

核心提示： 注意，您在 @doIt.when() 条件中可以指定的断言可以与 Python 代码中用来编写逻辑处理的 if 语句完全相同，深入 PEAK 的新特性(5)，然而，使用通用函数会更好；通用函数自己就会有些或多或少的特性，但是对于某个变量的条件产生的模糊性是应该限制的，它们可以是有关多个变量

注意，您在 @doIt.when() 条件中可以指定的断言可以与 Python 代码中用来编写逻辑处理的 if 语句完全相同。然而，使用通用函数会更好；通用函数自己就会有些或多或少的特性，因此不会在错误的地方使用 elif。功能最为强大的是，在后续代码中可以添加多个 @doIt.when() 条件，doIt() 以后就会开始将这个新条件作为一个候选者进行计算，从而满足特定调用的需求。

避免模糊性

不幸的是，一旦您开始编写通用的断言来描述自己希望在某个特定的函数体中处理的值时，就很容易创建一些模糊的条件。至少我在编写上面这个例子时就碰到了这种情况。比如清单 4 中的例子，就是我第一次编写的样子：

清单 4. 模糊断言描述 foo

@doIt.when("isinstance(foo,int) and isinstance(other,str)")
def doIt(foo, other):
　　print "foo is an unrestricted int |", foo, other
@doIt.when("3<=foo<=17 and isinstance(other,str)")
def doIt(foo, other):
　　print "foo is between 3 and 17 |", foo, other

每个条件本身都是非常理想的。但是对于 doIt(10,"flaz") 调用来说，两个都是真。PEAK 并不会猜想您可能想要怎样做，而会抛出一个 dispatch.interfaces.AmbiguousMethod 异常。

公平地说，我们毕竟应该指定惟一的条件，至少是一些可以由特殊性确定的条件。但是在碰到这些模糊性之前，我很长时间都认为定义一些断言通用函数就可以了。PEAK 只会在碰到会产生模糊性的调用时进行抱怨，而在可能定义一些模糊函数时却不会产生抱怨。

另外，即使上面这个例子看起来很容易发现这个问题，但是它却会变得更糟。毕竟，我们只不过声明了两个有关 foo 的重叠条件。但是对于某个变量的条件产生的模糊性是应该限制的。它们可以是有关多个变量的，这种模糊性可能只存在于某些特定的值的组合中。例如：