On Mon, May 18, 2020 at 12:03 AM Richard Damon
Some people (like myself, or the coworkers of [this person]( https://mail.python.org/archives/list/python-ideas@python.org/thread/PLXOXKA...)) just like to use asserts as a convenient way to check things. We don't want asserts to ever be turned off. Maybe there could be some kind of compiler
On 5/17/20 5:04 PM, Alex Hall wrote: directive which means "in this file, even with -O, keep the asserts". Maybe the line `assert __debug__`?
My answer to that is 'Your doing int wrong', that is like asking for an if statement to not bother checking some of its conditionl.
the assert operation has, like forever, been a debugging aid to say this condition should ALWAYS/NEVER occur, check for it in Debug Builds, but not for production builds. In some cases (some languages) the compiler might even optimize to code based on the knowledge that the condition, even in code executed before the condition (if it can be sure the assert will be reached).
That bit about other languages is fascinating! And a bit scary...
To quote the documentation:
Assertions should *not* be used to test for failure cases that can occur because of bad user input or operating system/environment failures, such as a file not being found.
I understand this, but I still don't understand in what situation people use assertions 'correctly'. To me an assert implies: 1. If the condition is false: that's bad, and the code shouldn't keep running. 2. I'm not 100% sure the condition is always true (a bug in my code is always a possiblity) and I need code to check for me. In that case I want the check there even more in production than in development. It never makes sense to me for such checks to be turned off. I understand the reason to turn them off is performance, but this always seems like a minor optimisation. I don't want code to be significantly slower without -O. For me it makes development and testing slow and painful, for users it pushes them to use a global switch to solve a local problem at the cost of safety. Really slow correctness checking is generally reserved for continuous integration tests. I've never wanted to put something significantly slow in an assert and I've never seen anyone else do that, or write in their documentation "this code is best used with -O". So the tradeoff always seems clear - accept a small performance hit for better peace of mind of correctness. If I was really concerned about speed, Python is already the wrong language.