使用断言的最佳时机偶尔会被提起，通常是因为有人误用，因此我觉得有必要写一篇文章来阐述一下什么时候应该用断言，为什么应该用，什么时候不该用。
对那些没有意识到用断言的最佳时机的人来说，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标识执行时它将导致代码被彻底中断。
那么我们什么时候应该使用断言呢？如果没有特别的目的，断言应该用于如下情况：
防御性的编程
运行时对程序逻辑的检测
合约性检查（比如前置条件，后置条件）
程序中的常量
检查文档
（断言也可以用于代码测试，用作一个做事毛手毛脚的开发人员的单元测试，只要能你接受当使用-O标志时这个测试什么都不做。我有时也会在代码中用"assert Fasle"来对还没有实现的分支作标记，当然我希望他们失败。如果稍微更细节一些，或许触发NotImplementedError是更好的选择）
因为程序员是对于代码正确性表现出的信心不同，因此对于什么时候使用断言的意见各不相同。如果你确信代码是正确的，那么断言没有任何意义，因为它们从不会失败，因此你可以放心地移除它们。如果你确信它们会失败（例如对用户输入的数据的检测），你不敢用断言，这样编译就能通过，但你跳过了你的检查。
在以上两种情况之间的情况就显得特别有趣了，那就是当你相信代码是正确的，但又不是特别确定的时候。或许你忘记了一些奇怪的边角情况（因为我们都是人），在这种情况下，额外的运行时检查将帮助你尽可能早地捕获错误，而不是写了一大堆代码之后。
（这就是为什么使用断言的时机会不同。因为我们对代码正确性的信息不同，对于一个人有用的断言，对于另一个人来说却是无用的运行时测试。）
另一个断言用得好的地方就是检查程序中的不变量。一个不变量是一些你能相信为真的条件，除非一个缺陷导致它变成假。如果有一个缺陷，越早发现越好，因此我们需要对其进行测试，但我们不想因为这些测试而影响代码执行速度。因此采用断言，它能在开发时生效而在产品中失效。
一个关于不变量的例子可能是这样的情况。如果你的函数在开始的时候期望一个打开的数据库连接，并且在函数返回后该数据库连接依然是打开的，这是一个函数的不变量：
def some_function(arg):
assert not DB.closed()
... # code goes here
assert not DB.closed()
return result
断言也是一个很好的检查点注释。为了替代如下注释：
#当我们执行到这里，我们知道n>2
你可以确保在运行时用以下断言：
assert n > 2
断言也是一种防御性的编程形式。你不是在防范当前代码发生错误，而防范由于以后的代码变更发生错误。理想情况下，单元测试应该直到这个作用，但是让我们面对这样一个现实：即使存在单元测试，他们在通常情况下也不是很完备。内建的机器人可能没有工作，但数周以来也没有人注意到它，或者人们在提交代码之前忘记了执行测试。内部检查将是防止错误渗入的另一道防线，尤其对于那些悄悄地失败，但会引起代码功能错误并返回错误结果的情况有效。
推荐阅读：