使用断言的最佳时机偶尔会被提起,通常是因为有人误用,因此我觉得有必要写一篇文章来阐述一下什么时候应该用断言,为什么应该用,什么时候不该用。
对那些没有意识到用断言的最佳时机的人来说,Python的断言就是检测一个条件,如果条件为真,它什么都不做;反之它触发一个带可选错误信息的AssertionError。如下例所示:
py> x = 23 py> assert x > 0, "x is not zero or negative" py> assert x%2 == 0, "x is not an even number" Traceback (most recent call last): File "<stdin>", line 1, in <module> AssertionError: x is not an even number很多人将断言作为当传递了错误的参数值时的一种快速而简便的触发异常的方式。但实际上这是错误的,而且是非常危险的错误,原因有两点。首先,AssertionError通常是在测试函数参数时给出的错误。你不会像下面这样编码:
if not isinstance(x, int): raise AssertionError("not and int")你应该用TypeError来替代,“断言”解决了错误的异常类型。
但是对断言来说更危险也更纠结的是:如果你执行Python时使用了-O或-OO优化标识,这能够通过编译却从来不会被执行,实际上就是说并不能保证断言会被执行。当恰当地使用了断言,这非常好的,但当不恰当地使用了断言,在使用-O标识执行时它将导致代码被彻底中断。
def some_function(arg): assert not DB.closed() ... # code goes here assert not DB.closed() return result断言也是一个很好的检查点注释。为了替代如下注释:
#当我们执行到这里,我们知道n>2
你可以确保在运行时用以下断言:
assert n > 2
断言也是一种防御性的编程形式。你不是在防范当前代码发生错误,而防范由于以后的代码变更发生错误。理想情况下,单元测试应该直到这个作用,但是让我们面对这样一个现实:即使存在单元测试,他们在通常情况下也不是很完备。内建的机器人可能没有工作,但数周以来也没有人注意到它,或者人们在提交代码之前忘记了执行测试。内部检查将是防止错误渗入的另一道防线,尤其对于那些悄悄地失败,但会引起代码功能错误并返回错误结果的情况有效。
假设你有一系列的if...elif代码块,你预先知道变量期望的值:
# target期望x, y或z中的一个值 if target == x: run_x_code() elif target == y: run_y_code() else: run_z_code()
假设这段代码现在完全正确。但它会一直正确吗?需求变更,代码变更。如果需求变为允许target = w,并关联到run_w_code,那将会发生什么情况?如果我们变更了设置target的代码,但是忘记了改变这个代码块,它就会错误地调用run_z_code(),错误就会发生。对于这段代码最好的方法就是编写一些防御性的检查,这样它的执行,即使在变更以后,要么正确,要么马上失败。
在代码开始添加注释是个好的开端,但是人们都不太喜欢读和更新这些注释,这些注释会很快变得过时。但对于断言,我们可以同时对这块代码编写文档,如果这些断言被违反了,会直接引起一个简单而又直接的失败。
assert target in (x, y, z) if target == x: run_x_code() elif target == y: run_y_code() else: assert target == z run_z_code()这里的断言同时用于防御性编程和检查文档。我认为这是最优的解决方案:
if target == x: run_x_code() elif target == y: run_y_code() elif target == z: run_z_code() else: # 这个不会发生,但是以防万一 raise RuntimeError("an unexpected error occurred")
def first_upper(astring): assert isinstance(astring, str) and len(astring) > 0 result = astring[0].upper() assert isinstance(result, str) and len(result) == 1 assert result == result.upper() return result