python - Python断言的使用场景有哪些

Question

谁能解释一下当使用和什么是最适合 断言的使用场景？

我的观点是:

因为它刚好等于 if not then raise

并在优化模式 -O它将被忽略

那么什么是 使用场景为 assert在源代码中(不是单元测试)？

根据我非常传统的经验， assert应该只存在于单元测试中，真的无法理解为什么它开始越来越多地出现在 Python 项目代码中。

Answer 1

将库代码中的断言语句视为加载注释的一种好方法是，它就像是关于代码如何工作(或您认为它是如何工作的)的一小段文档，如果“评论”总是提出一个结果证明是错误的主张。

什么时候使用断言？

当您将断言语句写入源代码(不是测试代码)时，您应该非常确信它不会触发，无论程序输入如何。当然，您不能 100% 确定它永远不会触发，但是您应该确定，如果它触发，那么您在某处做出了错误的假设，您需要重新访问代码的这一部分。

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

因为你会犯错，而且你并不完美。使用断言可以是 防范您自己的错误 .这就像当你锁上车门，然后试图抬起门 Handlebars 来检查它是否正常工作。

如果您在某处出错，它会阻止代码继续。一个普通的旧评论不能做到这一点。如果逻辑依赖于某些不正确的假设，则对该假设的精心编写的断言可以保护您免受不安全的代码执行的影响。这允许 代码的受控故障模式 ，而不是后来以某种奇怪的方式表现出来的错误，从而更难找到根本原因。

这是防御性编程的一种形式，可用于防止来自 future 的变化! 这是一个很好的技巧。 future 的您，或从事该项目的其他开发人员，可能会在以后的提交中添加一些代码，这会使您一年前做出的假设无效。断言语句就像这里的一个路标，上面写着“嘿，如果你改变了那个东西，你也需要在这里改变一些东西”，并提请注意一些微妙的实现细节，否则很容易错过。

何时不使用断言

不要使用它们来验证输入!如有必要，请使用异常(exception)。如果断言触发， 这是一个错误 .如果用户报告未处理 AssertionError ，这是您的问题，而不是用户的错。有什么需要解决的。

下面是一个错误断言的例子:

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

如果触发，那是调用者的错。如果你需要它，一个 TypeError在这里比未处理更合适 AssertionError .

下面是一个 ok 断言的例子:

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' 的处理。如果愚蠢的 future 会错误地分支 - 您在提示中添加了 6 个以上的选项，但只添加了其中 5 个选项的处理(哎呀!)