Python assert的使用场景是什么

Question

有人可以解释何时使用，什么是最佳的断言适用场景？

我的观点是：

• 既然等于 if not then raise
• 在优化模式下-O，它将被忽略

那么，源代码（而非单元测试）中的使用场景是assert什么？

从我的传统经验来看，assert应该只存在于单元测试中，实际上并不能理解为什么它开始越来越多地出现在Python项目代码中。

Answer 1

在库代码中考虑断言的一个好方法是将其作为已加载的注释，这就像是一小段有关该代码如何工作（或您认为它如何工作）的文档，如果使用该注释会大打折扣。 “评论”曾经断言是错误的。

何时使用断言？

在将断言语句写入源代码（而不是测试代码）时，无论程序输入如何，都应该确信它不会触发。当然，您不能百分百确定它永远不会触发，但是您应该确保，如果它会触发，那么您在某处做出了错误的假设，则需要重新查看本节代码。

为什么要将断言添加到库代码中呢？如果您确定他们不会开火，那有什么意义呢？

1. 因为你犯了错误，但你并不完美。使用断言可以防止自己的错误。就像您锁上车门，然后尝试抬起车门把手以检查车门是否正常工作。
2. 如果您在某处出错了，它将阻止代码继续执行。普通的旧评论无法做到这一点。如果逻辑依赖于某些不正确的假设，则对该假设的正确编写的断言可以保护您免受代码的不安全执行的影响。这样就可以控制代码的失败模式，而不是以后以某种怪异的方式显示错误，从而更加难以找到根本原因。
3. 这是一种防御性编程形式，可用于防御未来的变化！这是一个好把戏。将来您或其他从事项目工作的开发人员可能会在以后的提交中添加一些代码，这会使您一年前所做的假设无效。断言语句就像一个路标，上面写着：“嘿，如果您更改了该内容，则也需要在此处进行更改”，并提请注意一些实现细节，否则可能会容易错过。

什么时候不使用断言

不要使用它们来验证输入！如有必要，请使用例外。如果断言发生，那就是一个错误。如果用户报告未处理AssertionError，这是您的问题，而不是用户的错。需要修复某些问题。

这是一个错误断言的示例：

def square(n):
    assert isinstance(n, int)
    ...

如果触发，那是呼叫者的错。如果需要，TypeError这里a比未处理的更合适AssertionError。

这是一个好的断言的例子：

s = None
while s not in {'y', 'n'}:
    s = input("do the thing? [y/n] ").lower()
if s == 'y':
    # do the thing
else:
    assert s == 'n'
    # do other stuff 

它不会验证数据，即用户无法键入任何会引起断言触发的输入-开发人员在此处所做的“假设”是由于while循环已退出，因此s必须为'y'或'n'。这是不是一个更好的elif s == 'n':，else: raise结构类型，因为else:块永远无法达到，所以它不会，除非你做一些真正侵入嘲讽接收测试覆盖率。最后但并非最不重要的一点是，它可以防止'n'在愚蠢的将来时错误输入分支的处理方式-您在提示中增加了6个选择，但仅添加了其中5个选择的处理（哎呀！）