2QdxY4RzWzUUiLuE＠potatochowder.com wrote:
What about asserts that are not used for testing, but as classic “unless there’s a bug, this should hold”? Those may not want to incur the extra cost. I was actually thinking exactly the opposite: this would more useful in
On 2021-09-12 at 07:28:53 -0700, Guido van Rossum guido@python.org wrote: production than in testing. When I'm testing, tests build on each other. I should know that the inner parts work, and I should be testing specific aspects of the outer parts. If I don't have confidence in those inner parts, then I need to write more tests against them. If I don't "know" where the data comes from in my assertions, then my tests are trying to test too much at once. On the other hand, weird things happen in production, and my first reaction to "this shouldn't happen unless there's a bug" are is to start looking in the logs at how we got there. These power assertions are like a retroactive or JIT logging mechanism (in the sense that I may not have logged enough detail), or a sort of first order run-time debugger that shows me what's relevant at the point of the failure. As far as the extra cost goes, how does that cost compare to the full stack trace I already get from the exception being raised?
That's an interesting observation. I haven't thought of that. Regarding cost - I haven't profiled my implementation, so I'll have to get back to you on that one.