使用断言的最佳实践？

Question

1. 使用 assert 作为标准代码的一部分而不是仅用于调试目的是否会出现性能或代码维护问题？

   是

   断言 x >= 0, 'x 小于零' 
     

   比更好或更差

   如果 x <   0: 
         引发异常（'x 小于零'） 
     

2. 另外，有没有办法设置像 if x << 0 引发错误，始终在没有 try/ except/finally 的情况下进行检查，因此，如果在整个代码中的任何时候 x 小于 0，则会引发错误，就像你设置 assert x < 0 在函数开始处，函数内任何 x 小于 0 的地方都会引发异常？

Answer 1

英语单词断言在这里的意思是发誓、确认< /em>，承认。 它并不意味着“检查”或“应该”。 这意味着您作为编码员在此做出宣誓声明：

# 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

如果代码正确，则禁止单事件干扰、硬件故障等，任何断言都不会失败。 这就是为什么程序对最终用户的行为不能受到影响。 特别是，即使在特殊的编程条件下，断言也不会失败。 它只是永远不会发生。 如果发生这种情况，程序员就应该受到惩罚。

Answer 2

正如前面所说，当您的代码不应该达到某个点（这意味着那里存在错误）时，应该使用断言。 我认为使用断言的最有用的原因可能是不变/前置/后置条件。 这些在循环或函数的每次迭代开始或结束时必须为真。

例如，递归函数（2 个独立的函数，因此 1 个处理错误的输入，另一个处理错误的代码，因为很难与递归区分开）。 如果我忘记写 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

这些循环不变量通常可以用断言来表示。

Answer 3

无论如何，如果您正在处理依赖 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

Answer 4

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

目的

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

接下来，它是为了“调试目的”，虽然这是正确的，但听起来非常不屑一顾。 我更喜欢“声明不变量，永远不应该违反”的表述，尽管它对不同的初学者有不同的作用......有些人“只是明白”，而另一些人要么没有发现它有任何用处，要么替换正常的异常，甚至用它来控制流量。

风格

在 Python 中，assert 是一条语句，而不是一个函数！ （记住 assert(False, 'is true') 不会引发。但是，解决这个问题：

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

通常有许多专用方法来执行断言（assertTrue(condition)、assertFalse(condition)、assertEqual(actual, Expected)等）。

在某些情况下，您可以在不需要的代码中

对断言进行注释：

def dump(something):
断言 isinstance（某物，可转储）
# ...

但除此之外，消息对于与其他程序员（有时是代码的交互式用户，例如在 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 be equal to b 也是可读的，并且该语句在代码中看起来很合乎逻辑。 此外，您可以在不读取回溯的情况下从中获取一些东西（有时甚至不可用）。

Answer 5

是否存在性能问题？

• 请记住“先让它工作，然后再让它快速工作”。
  任何程序中很少有一部分与其速度相关。
  如果事实证明，您始终可以删除或简化断言
  成为一个性能问题——而且大多数永远不会。

• 务实：
  假设您有一个处理非空元组列表的方法，并且如果这些元组不是不可变的，则程序逻辑将中断。 你应该写：

  def mymethod(listOfTuples): 
        断言(all(type(tp)==listOfTuples中tp的元组)) 
    

  如果您的列表往往有十个条目那么这可能没问题，但是
  如果他们有一百万个条目，这可能会成为一个问题。
  但与其完全丢弃这张有价值的支票，您可以
  只需将其降级为

  def mymethod(listOfTuples): 
        assert(type(listOfTuples[0])==tuple) # 事实上 _all_ 必须是元组！ 
    

  这很便宜，但无论如何都可能捕获大多数实际程序错误。

Answer 6

assert 的使用和异常的引发都与通信有关。

• 断言是针对开发人员的关于代码正确性的声明：代码中的断言告知代码的读者有关代码正确性必须满足的条件。 运行时失败的断言会通知开发人员代码中存在需要修复的缺陷。

• 异常是关于非典型情况的指示，这些情况可能在运行时发生，但无法由手头的代码解决，在要在那里处理的调用代码处解决。 异常的发生并不表明代码中存在错误。

最佳实践

因此，如果您将运行时出现的特定情况视为错误，您希望通知开发人员（“开发人员您好，此情况表明某处存在错误，请修复代码。” ）然后进行断言。 如果断言检查代码的输入参数，则通常应在文档中添加当输入参数违反该条件时代码具有“未定义的行为”的信息。

相反，如果这种情况的发生并不表明您认为存在错误，而是您认为应该由客户端代码处理的（可能罕见但）可能的情况，请引发异常。 引发异常的情况应该是相应代码文档的一部分。

使用 assert 是否存在性能问题

断言的评估需要一些时间。 不过，它们可以在编译时消除。 然而，这会产生一些后果，请参见下文。

使用 assert 是否存在 [...] 代码维护问题

通常断言可以提高代码的可维护性，因为它们通过明确假设并在运行时定期验证这些假设来提高可读性。 这也将有助于捕捉回归。 然而，需要牢记一个问题：断言中使用的表达式不应有副作用。 如上所述，可以在编译时消除断言 - 这意味着潜在的副作用也会消失。 这可能会无意中改变代码的行为。

Answer 7

断言是要检查 -
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' 为 null。 因此，我们通过 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
什么都不会打印

Answer 8

在 PTVS、PyCharm、Wing 等 IDE 中，可以使用 assert isinstance() 语句来为一些不清楚的对象启用代码补全。

Answer 9

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

它们的目的既是告知读者，帮助我推理，并检查我的推理没有犯错误。 例如：

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 在优化模式下运行时断言被禁用，因此请毫不犹豫地在其中编写昂贵的条件，特别是如果它使您的代码更清晰和更少容易出现错误

Answer 10

设置业务规则，例如 if x < 0 引发错误

据我所知，对此没有通用的（与实现无关的）解决方案。

但是，如果 x 是某个类 C 的对象的属性，则可以通过将普通属性 x 转换为 x 来完成strong>属性 x 不仅有 getter，还有 setter：

https://docs.python.org/3/library/functions.html#property

然后，setter 可以实现并强制执行业务规则。

Answer 11

断言应用于测试不应该发生的条件。 目的是在程序状态损坏的情况下尽早崩溃。

异常应该用于可能发生的错误，并且您几乎应该总是创建自己的异常类。

---

例如，如果您正在编写一个从配置文件读取到 dict 的函数，则文件中的格式不正确会引发 ConfigurationSyntaxError，而您可以 断言您不会返回None。

---

在您的示例中，如果 x 是通过用户界面或外部源设置的值，则最好是例外。

如果 x 仅由您自己的代码在同一程序中设置，请使用断言。

Answer 12

优化编译时删除“assert”语句。 所以，是的，性能和功能都存在差异。

当编译时请求优化时，当前代码生成器不会为断言语句发出任何代码。 - Python 2 文档 Python 3 文档

如果您使用 assert 来实现应用程序功能，那么优化生产部署，您将受到“but-it-works-in-dev”缺陷的困扰。

请参阅 PYTHONOPTIMIZE 和 -O -OO

Answer 13

当整个函数中 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

Answer 14

assert 的四个目的

假设您与四位同事 Alice、Bernd、Carl 和 Daphne 一起处理 200,000 行代码。
他们调用您的代码，您调用他们的代码。

那么 assert 有四个角色：

1. 告知 Alice、Bernd、Carl 和 Daphne 您的代码期望什么。
   假设您有一个处理元组列表的方法，并且如果这些元组不是不可变的，则程序逻辑可能会中断：

   def mymethod(listOfTuples): 
         断言(all(type(tp)==listOfTuples中tp的元组)) 
     

   这比文档中的同等信息更值得信赖
   并且更容易维护。

2. 告知计算机您的代码需要什么。
   assert 强制代码调用者采取正确的行为。
   如果你的代码调用 Alices 的代码，而 Bernd 的代码调用你的代码，
   然后，如果没有 assert，如果程序在 Alice 代码中崩溃，
   伯恩德可能认为这是爱丽丝的错，
   爱丽丝调查后可能会认为这是你的错，
   你调查并告诉伯恩德这实际上是他的。
   很多工作都丢掉了。
   有了断言，无论谁接到错误的电话，他们很快就能发现这是错误的
   他们的错，不是你的。 爱丽丝、伯恩德和你们都会受益。
   节省大量时间。

3. 告知您的代码的读者（包括您自己）您的代码在某个时刻取得了哪些成就。
   假设您有一个条目列表，并且每个条目都可以是干净的（这很好）
   或者它可以是smorsh、trale、gullup或twinkled（这些都是不可接受的）。
   如果它是smosh的，那么它必须是unsmoshed的； 如果它是真实的，那么它一定是歪曲的；
   如果它是咕噜咕噜的，那么它必须小跑（然后可能也有节奏）；
   如果它闪烁，除了星期四之外，它必须再次闪烁。
   你明白了：这是很复杂的事情。
   但最终结果是（或应该是）所有条目都是干净的。
   正确的事情(TM) 要做的是总结您的影响
   清洁循环为

   assert(all(entry.isClean() 用于 mylist 中的条目)) 
     

   这种说法让每个试图理解的人都感到头疼
   奇妙的循环正在实现什么到底。
   这些人中最常出现的可能就是您自己。

4. 告知计算机您的代码在某个时刻取得了哪些成果。
   如果您在小跑后忘记为需要它的条目配速，
   assert 将节省您的时间并避免您的代码
   亲爱的达芙妮的打破要晚得多。

在我看来，assert 文档的两个目的（1 和 3）和
保障措施（2 和 4）同样有价值。
通知人们甚至可能比通知计算机更有价值
因为它可以防止 assert 旨在捕获的错误（在情况 1 中）
无论如何，随后还会犯很多错误。

Answer 15

除了其他答案之外，断言本身也会引发异常，但仅限于 AssertionErrors。 从功利主义的角度来看，当您需要对捕获的异常进行细粒度控制时，断言不适合。

Answer 16

这种方法唯一真正错误的是，很难使用断言语句做出非常具有描述性的异常。 如果您正在寻找更简单的语法，请记住您可以也可以执行以下操作：

class XLessThanZeroException(Exception):
    pass

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

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

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