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?
当前回答
英语单词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
如果代码是正确的，除了单事件中断、硬件故障等，任何断言都不会失败。这就是为什么程序对终端用户的行为不能受到影响。特别是，断言即使在异常的编程条件下也不能失败。这种事从来没有发生过。如果发生这种情况，程序员应该为此受到惩罚。
其他回答
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 没有东西会被打印出来
如前所述，当您的代码should NOT到达某个点(意味着那里存在错误)时，应该使用断言。在我看来，使用断言最有用的原因可能是不变量/前置/后置条件。在循环或函数的每次迭代的开始或结束时，这些必须为真。
例如，一个递归函数(两个独立的函数，一个处理错误的输入，另一个处理错误的代码，因为它很难与递归区分开来)。如果我忘记写if语句，这将很明显地显示出哪里出了问题。
def SumToN(n):
if n <= 0:
raise ValueError, "N must be greater than or equal to 0"
else:
return RecursiveSum(n)
def RecursiveSum(n):
#precondition: n >= 0
assert(n >= 0)
if n == 0:
return 0
return RecursiveSum(n - 1) + n
#postcondition: returned sum of 1 to n
这些循环不变量通常可以用断言表示。
我补充说，我经常使用断言来指定属性，比如循环不变量或我的代码应该具有的逻辑属性，就像我在正式验证的软件中指定它们一样。
它们有两个目的，告诉读者，帮助我推理，并检查我在推理中没有犯错误。例如 :
k = 0
for i in range(n):
assert k == i * (i + 1) // 2
k += i
#do some things
或者在更复杂的情况下:
def sorted(l):
return all(l1 <= l2 for l1, l2 in zip(l, l[1:]))
def mergesort(l):
if len(l) < 2: #python 3.10 will have match - case for this instead of checking length
return l
k = len(l // 2)
l1 = mergesort(l[:k])
l2 = mergesort(l[k:])
assert sorted(l1) # here the asserts allow me to explicit what properties my code should have
assert sorted(l2) # I expect them to be disabled in a production build
return merge(l1, l2)
因为当python在优化模式下运行时，断言是禁用的，所以不要犹豫在它们中编写代价高昂的条件，特别是当它使您的代码更清晰，更不容易出现错误时
在诸如PTVS、PyCharm、Wing assert isinstance()等IDE中，可以使用isinstance语句对一些不清楚的对象启用代码补全。
这种方法唯一真正的错误是，很难使用断言语句产生非常描述性的异常。如果你正在寻找更简单的语法，记住你也可以这样做:
class XLessThanZeroException(Exception):
pass
def CheckX(x):
if x < 0:
raise XLessThanZeroException()
def foo(x):
CheckX(x)
#do stuff here
另一个问题是，使用assert进行正常的条件检查会使使用-O标志禁用调试断言变得困难。
