Is there a performance or code maintenance issue with using assert as part of the standard code instead of using it just for debugging purposes? Is assert x >= 0, 'x is less than zero' better or worse than if x < 0: raise Exception('x is less than zero') Also, is there any way to set a business rule like if x < 0 raise error that is always checked without the try/except/finally so, if at anytime throughout the code x is less than 0 an error is raised, like if you set assert x < 0 at the start of a function, anywhere within the function where x becomes less then 0 an exception is raised?


当前回答

这是一个悬而未决的问题,我有两个方面想涉及:何时添加断言以及如何编写错误消息。

目的

向初学者解释一下,断言是一种可能引发错误的语句,但您不会捕获它们。他们通常不应该被抚养,但在现实生活中,他们有时还是会被抚养。这是一个严重的情况,代码无法恢复,我们称之为“致命错误”。

其次,它是为了“调试目的”,虽然正确,但听起来非常轻蔑。我更喜欢“声明不变量,它永远不应该被违反”的提法,尽管它对不同的初学者有不同的作用……有些人“只是得到它”,而另一些人要么没有找到它的任何用途,要么取代正常的异常,甚至用它来控制流。

风格

在Python中,assert是语句,而不是函数!(记住assert(False, 'is true')不会引发。但是,先说一下:

何时以及如何编写可选的“错误消息”?

这实际上适用于单元测试框架,它通常有许多专用的方法来执行断言(assertTrue(条件),assertFalse(条件),assertEqual(实际的,预期的)等)。它们通常还提供了一种对断言进行评论的方法。

在一次性代码中,您可以不使用错误消息。

在某些情况下,没有什么可以添加到断言:

def垃圾场(东西): 屁 # ...

但除此之外,消息对于与其他程序员(有时是你代码的交互式用户,例如在Ipython/Jupyter等)的交流是有用的。

给他们信息,而不仅仅是泄露内部实现细节。

而不是:

assert meaningless_identifier <= MAGIC_NUMBER_XXX, 'meaningless_identifier is greater than MAGIC_NUMBER_XXX!!!'

写:

assert meaningless_identifier > MAGIC_NUMBER_XXX, 'reactor temperature above critical threshold'

或者甚至:

assert meaningless_identifier > MAGIC_NUMBER_XXX, f'reactor temperature({meaningless_identifier }) above critical threshold ({MAGIC_NUMBER_XXX})'

我知道,我知道——这不是静态断言的情况,但我想指出消息的信息值。

消极还是积极的信息?

这可能是有争议的,但读到这样的东西让我很受伤:

assert a == b, 'a is not equal to b'

这是两个相互矛盾的东西。因此,每当我对代码库产生影响时,我就会通过使用“必须”和“应该”等额外的动词来明确我们想要什么,而不是说我们不想要什么。 断言a == b, 'a必须等于b'

然后,获取AssertionError: a must equal to b也是可读的,并且语句在代码中看起来是合乎逻辑的。此外,您可以在不读取回溯(有时甚至不可用)的情况下从中获得一些信息。

其他回答

无论如何,如果你处理的代码依赖assert来正常工作,那么添加以下代码将确保assert被启用:

try:
    assert False
    raise Exception('Python assertions are not working. This tool relies on Python assertions to do its job. Possible causes are running with the "-O" flag or running a precompiled (".pyo" or ".pyc") module.')
except AssertionError:
    pass

这种方法唯一真正的错误是,很难使用断言语句产生非常描述性的异常。如果你正在寻找更简单的语法,记住你也可以这样做:

class XLessThanZeroException(Exception):
    pass

def CheckX(x):
    if x < 0:
        raise XLessThanZeroException()

def foo(x):
    CheckX(x)
    #do stuff here

另一个问题是,使用assert进行正常的条件检查会使使用-O标志禁用调试断言变得困难。

英语单词assert在这里的意思是发誓、肯定、宣称。它的意思不是“检查”或“应该是”。这意味着你作为一个程序员要在这里做一个宣誓声明:

# I solemnly swear that here I will tell the truth, the whole truth, 
# and nothing but the truth, under pains and penalties of perjury, so help me FSM
assert answer == 42

如果代码是正确的,除了单事件中断、硬件故障等,任何断言都不会失败。这就是为什么程序对终端用户的行为不能受到影响。特别是,断言即使在异常的编程条件下也不能失败。这种事从来没有发生过。如果发生这种情况,程序员应该为此受到惩罚。

是否存在性能问题?

Please remember to "make it work first before you make it work fast". Very few percent of any program are usually relevant for its speed. You can always kick out or simplify an assert if it ever proves to be a performance problem -- and most of them never will. Be pragmatic: Assume you have a method that processes a non-empty list of tuples and the program logic will break if those tuples are not immutable. You should write: def mymethod(listOfTuples): assert(all(type(tp)==tuple for tp in listOfTuples)) This is probably fine if your lists tend to be ten entries long, but it can become a problem if they have a million entries. But rather than discarding this valuable check entirely you could simply downgrade it to def mymethod(listOfTuples): assert(type(listOfTuples[0])==tuple) # in fact _all_ must be tuples! which is cheap but will likely catch most of the actual program errors anyway.

Assert是检查- 1. 有效条件, 2. 有效的表述, 3.真正的逻辑; 源代码。它不会让整个项目失败,而是会发出警报,提示源文件中有些地方不合适。

在例1中,因为变量'str'不是空的。因此不会引发任何断言或异常。

示例1:

#!/usr/bin/python

str = 'hello Python!'
strNull = 'string is Null'

if __debug__:
    if not str: raise AssertionError(strNull)
print str

if __debug__:
    print 'FileName '.ljust(30,'.'),(__name__)
    print 'FilePath '.ljust(30,'.'),(__file__)


------------------------------------------------------

Output:
hello Python!
FileName ..................... hello
FilePath ..................... C:/Python\hello.py

在例2中,var 'str'为空。因此,我们可以通过assert语句来避免用户走在错误程序前面。

示例2:

#!/usr/bin/python

str = ''
strNull = 'NULL String'

if __debug__:
    if not str: raise AssertionError(strNull)
print str

if __debug__:
    print 'FileName '.ljust(30,'.'),(__name__)
    print 'FilePath '.ljust(30,'.'),(__file__)


------------------------------------------------------

Output:
AssertionError: NULL String

当我们不想调试并意识到源代码中的断言问题时。禁用优化标志

python -O assertStatement.py 没有东西会被打印出来