Question

有人可以解释使用 WHEN 以及断言的 BEST SUITABLE 使用方案是什么？

我的观点是：

因为它等于if not then raise
在优化模式-O中，它将被忽略

那么源代码（不是单元测试）中assert的使用方案是什么？

从我非常传统的经验来看，assert应该只存在于单元测试中，真的不能说明为什么它越来越多地出现在Python项目代码中。

Answer 1

在库代码中考虑断言语句的好方法是作为加载的注释，它就像一段关于代码如何工作的文档（或者你如何看待它）如果＆＃34;评论＆＃34;那将会爆炸并发出巨大的噪音一直在提出一个证明是错误的主张。

何时使用assert？

当您在源代码（而不是测试代码）中编写断言语句时，您应该非常确信它不会触发，无论程序输入。当然，你不能100％确定它永远不会开火，但是你应该确定如果要开火那么你在某个地方做了一个不正确的假设并且你将会这样做需要重新审视代码的这一部分。

为什么将断言添加到库代码中？如果你确定他们不会被解雇，那么重点是什么？

因为你犯了错误而且你并不完美。使用断言可以防范您自己的错误。这就像当你锁上车门，然后通过试图抬起门把手检查它是否正常工作。
如果您在某处犯了错误，它会阻止代码继续运行。一个普通的评论不能这样做。如果逻辑依赖于一些不正确的假设，那么这个假设的写得很好的断言可以保护您免受代码的不安全执行。这允许代码的受控故障模式，而不是稍后以某种奇怪方式显示的错误，从而更难找到根本原因。
这是一种防御性编程形式，可用于防止未来发生变化！这是一个很好的技巧。未来您或其他从事项目工作的开发人员可能会在以后的提交中添加一些代码，这会使您在一年前做出的假设失效。断言就像一个路标，说'嘿，如果你改变了那个东西，你也需要在这里改变一些东西＆＃34;并提请注意一些可能很容易错过的细微实现细节。

何时不使用断言

不要用它们来验证输入！如有必要，请使用例外。如果断言触发，那是一个错误。如果用户报告未处理的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

它不会验证数据，即用户无法输入会导致断言触发的任何输入 - ＆＃34;假设＆＃34;开发人员在这里做的是，由于while循环已退出，s必须为'y'或'n'。这比elif s == 'n':，else: raise类型构造更好，因为永远无法访问else:块，因此除非您进行一些非常具有侵入性的模拟，否则它将无法获得测试覆盖率。最后但并非最不重要的是，如果愚蠢的未来，它可以防止错误地进入'n'分支的处理 - 您在提示中添加了6个选项，但只为其中5个选项添加处理（哎呀！）

Python断言的用法场景是什么？

1 个答案:

何时使用assert？

何时不使用断言