请听到我的声音。我知道assert的工作原理。
就上下文而言，我想到的某些应用程序和用法涉及通过GUI进行数学优化，因此这些函数可以被调用数亿次。
assert语句在优化模式（-O）中被禁用，因此，根据大多数人的意见（也许不仅仅是一种意见，），依赖它是不明智的做法（阅读：capital sin），我不知道）。
说我有以下函数可以计算圆的面积：
def area_circle(r):
return 3.141592654 * (r**2)
是的，我知道，没有文档字符串。这是一个玩具的例子。为了确保radius是int或float，我可以这样做：
def area_circle(r):
assert isinstance(r, (int, float), 'TypeError: Expected int or float, not ' + type(r).__name__
return 3.141592654 * (r**2)
我的建议可能应该公开执行，因为我将其视为一项简洁的功能，可以在开发时进行一些输入检查等，但是当我达到生产就绪状态时，我可以只需在优化模式下禁用代码中不必要的部分即可。如果我的系统测试涵盖了导致使用area_circle的工作流程，那么我个人不希望看到raise语句，因为它们只是浪费。
所以，如何不使用assert而不降低应用程序速度的方式进行集成系统测试？
编辑1
这里还有另外两个要考虑的信息：
您的论点似乎是assert语句非常适合调试（它们确实是），并且您的用例中的you可以对每个代码路径进行足够的单元测试，因此您可以放心地切换它们生产期间关闭以获取性能，并且您现在怀疑[every可能使用显式raise语句。
好吧，并非每个代码都可以在该程度上进行测试。有“在最前线”的代码，必须执行输入验证在运行时，并且必须使用显式检查和显式raise语句。很好的情况是，[[you无需担心后端代码会担心输入验证，因为您很有信心在上一层进行处理。在这种情况下，请不要进行输入验证并关闭assert语句。这并不意味着在每种情况下都有可能。例如，您的前端仍然需要显式的运行时检查，并且可能在内部显式raise错误。
raise语句适用于您的程序遇到无法处理的例外情况
。您的代码向以500 Internal Error响应的远程服务器发出HTTP请求。这是例外情况。那不是您的代码的幸福之路。这是您的代码无法处理的情况，它只能在运行时发生，无法通过单元测试来阻止。在这种情况下，raise例外是一件非常明智的事情。