问为什么assert没有被大量使用？

EN

我猜assert不经常被使用的主要原因是没有人使用Python的“优化”模式。

断言是检测编程错误的一个很好的工具，可以防止出现意外情况，但所有这些错误检查都是有代价的。在C/C++等编译语言中，这并不重要，因为断言只在调试版本中启用，并从发布版本中完全删除。

另一方面，在Python中，调试模式和发布模式之间没有严格的区别。解释器提供了一个“优化标志”(-O)，但目前这实际上并没有优化字节码，而只是删除了断言。

因此，大多数Python用户只是忽略-O标志，并在“正常模式”下运行他们的脚本，这是一种调试模式，因为asserts是启用的，并且__debug__是True，但被认为是“生产就绪”。

也许更明智的做法是切换逻辑，即默认情况下“优化”，只在显式调试模式(*)下启用断言，但我猜这会让许多用户感到困惑，我怀疑我们是否会看到这样的变化。

((*)这就是Java是如何做到这一点的，它提供了一个-ea (启用断言)开关。)

有几个原因浮现在脑海中。

它不是主函数

许多程序员，让我们不要被原理所困，他们不尊重任何不是程序倒数第二功能的直接参与者的东西。断言语句旨在用于调试和测试，因此，这是他们负担不起的奢侈品。

单元测试

assert语句早于单元测试的兴起和兴起。虽然assert语句仍然有其用途，但单元测试现在被广泛用于构建一个恶意环境，用来痛击某个子例程及其系统。在这种情况下，断言语句开始感觉像枪战中的刀子。

提高了业界对测试的尊重

assert语句是最好的最后一道防线。在C语言统治世界的时候，它上升到了高不可及的高度，成为实现新的“防御性编程”的一种很好的方式；它在灾难摇摇欲坠的边缘时识别并捕获灾难。这是在测试的价值得到广泛认可和尊重以及灾难变得更加普遍之前。

今天，任何严肃的商业软件都没有经过某种形式的测试就发布了，这是闻所未闻的。测试被认真对待，并已演变为一个庞大的领域。有测试专业人员和质量保证部门，他们有很大的检查表和正式的签字。在这种情况下，程序员往往不会为断言而烦恼，因为他们相信他们的代码将受到如此多令人厌倦的测试，以至于奇怪的灾难边缘条件的可能性是如此之小，以至于可以忽略不计。这并不是说他们是对的，但是如果懒惰编程的责任可以转移到QA部门，为什么不呢？

我不是这些项目的作者，所以这只是一个基于我自己经验的猜测。如果不直接问那些项目中的人，你不会得到一个具体的答案。

当你试图在自己的应用程序中进行调试等工作时，Assert是很棒的。但是，正如您提供的链接中所述，当应用程序可能能够预测状态并从状态中恢复时，使用条件更好。我没有使用过zope，但在Twisted和Django中，它们的应用程序都能够从代码中的许多错误中恢复并继续运行。在某种意义上，他们已经“编译”掉了断言，因为他们实际上可以处理这些断言。

与此相关的另一个原因是，通常使用外部库的应用程序可能希望进行错误处理。如果该库只是使用断言，那么无论是什么错误，它都会引发一个AssertionError。使用条件，这些库实际上可以抛出有用的错误，您的应用程序可以捕获和处理这些错误。