无论如何，如果你处理的代码依赖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

当x在整个函数中小于零时，能够自动抛出错误。您可以使用类描述符。这里有一个例子:

class LessThanZeroException(Exception):
    pass

class variable(object):
    def __init__(self, value=0):
        self.__x = value

    def __set__(self, obj, value):
        if value < 0:
            raise LessThanZeroException('x is less than zero')

        self.__x  = value

    def __get__(self, obj, objType):
        return self.__x

class MyClass(object):
    x = variable()

>>> m = MyClass()
>>> m.x = 10
>>> m.x -= 20
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "my.py", line 7, in __set__
    raise LessThanZeroException('x is less than zero')
LessThanZeroException: x is less than zero

是否存在性能问题?

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.

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

目的

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

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

风格

在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也是可读的，并且语句在代码中看起来是合乎逻辑的。此外，您可以在不读取回溯(有时甚至不可用)的情况下从中获得一些信息。

我补充说，我经常使用断言来指定属性，比如循环不变量或我的代码应该具有的逻辑属性，就像我在正式验证的软件中指定它们一样。

它们有两个目的，告诉读者，帮助我推理，并检查我在推理中没有犯错误。例如 :

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在优化模式下运行时，断言是禁用的，所以不要犹豫在它们中编写代价高昂的条件，特别是当它使您的代码更清晰，更不容易出现错误时

英语单词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

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