为什么断言不被大量使用？
我发现Python的assert语句是一个很好的方式来捕捉不应该发生的情况 。 当代码被信任为正确的时候，它可以通过Python优化来移除。
这似乎是在debugging模式下运行Python应用程序的完美机制。 但是看看django，twisted和zope等几个Python项目， assert几乎从来没有用过。 那么，为什么会这样呢？
为什么在Python社区中不常使用断言语句？
我猜测assert不被更经常使用的主要原因是没有人使用Python的“优化”模式 。
断言是检测编程错误的好工具，可以防范意外情况，但所有这些错误检查都会带来成本。 在C / C ++等编译语言中，这并不重要，因为断言仅在debugging版本中启用，并且完全从发行版本中删除。
另一方面，在Python中， debugging和发布模式之间没有严格的区别。 解释器具有一个“优化标志”（ -O ），但是目前这实际上并没有优化字节码，只是删除了断言。
因此，大多数Python用户只是忽略-O标志并在“正常模式”下运行它们的脚本，这是一种debugging模式，因为assert被启用， __debug__为True ，但被认为是“生产就绪”。
也许更聪明的做法是切换逻辑，即默认“优化”，只启用明确的debugging模式（*），但我想这会让很多用户感到困惑，我怀疑我们会看到这样的变化。
（（*）这是例如Java虚拟机如何通过使用-ea （enable assertions）开关来实现的。）
出现了几个原因…
这不是主要function
许多程序员不会因为理由而陷入困境，不尊重任何不是程序倒数第二个function的直接参与者。 断言陈述旨在用于debugging和testing，所以，他们不能承受的奢侈品。
unit testing
断言声明早于unit testing的兴起和兴起。 虽然主张声明仍然有其用处，unit testing现在被广泛用于构build一个恶劣的环境，用它来打乱一个子程序及其系统。 在这种情况下，断言就像枪战中的刀子一样。
改进了行业对testing的尊重
主张声明是最后一道防线。 在语言统治世界的时候，C语言升到了高不可攀的高度，是实施新的“防御性编程”的好方法。 它承认并陷入灾难性的灾难，在他们濒临崩溃的那一刻。 这之前，testing的价值得到了广泛的认可和尊重，灾难更为普遍。
今天，没有任何严肃的商业软件在没有某种forms的testing的情况下被发布，这是闻所未闻的。 testing被认真对待并且演变成一个巨大的领域。 有testing专业人员和质量保证部门有大的清单和正式的签字。 在这种情况下，程序员往往不会因为断言而烦恼，因为他们相信他们的代码将经受如此多的繁琐testing，以至于古怪的边缘条件的可能性非常之小以至于微不足道。 这并不是说他们是对的，但如果懒惰编程的责任可以转移到质量保证部门，为什么不呢？
我不是这些项目的作者，所以这只是一个基于我自己的经验的猜测。 如果不直接询问这些项目中的人员，你将不会得到具体的答案。
当你试图在自己的应用程序中进行debugging时，断言是很好的。 正如你所提供的链接所述，当应用程序能够预测并从状态恢复时，使用条件更好。 我没有使用过zope，但是在Twisted和Django中，它们的应用程序都能够恢复并继续执行代码中的许多错误。 从某种意义上说，他们已经“把”这些断言“编成”了，因为他们实际上可以处理这些断言。
与此相关的另一个原因是，经常使用外部库的应用程序（如列出的应用程序可能想要执行error handling）。 如果库只是使用断言，不pipe错误是什么，都会引发一个AssertionError 。 有条件的，图书馆实际上可以抛出有用的错误，可以被你的应用程序抓住和处理。
根据我的经验， assert主要用于程序的开发阶段 – 检查用户定义的input。 确实不需要编程错误。 Python本身是非常好的陷阱像ZeroDivisionError, TypeError等真正的编程错误。
