On 5/18/20 5:25 AM, Alex Hall wrote: > On Mon, May 18, 2020 at 12:03 AM Richard Damon > <rich...@damon-family.org <mailto:rich...@damon-family.org>> wrote: > > On 5/17/20 5:04 PM, Alex Hall wrote: > > Some people (like myself, or the coworkers of [this > > person](https://mail.python.org/archives/list/python-ideas@python.org/thread/PLXOXKACKGXN4ZKISDVXLKMFIETWTF63/)) > 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 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.
The idea is that during debug, you have added sentinel checking the pre- and post- conditions to routines. Pre-conditions are those requirements that MUST be met to call the function, things that the caller was supposed to make sure were true to begin with (either from other routines post conditions or what it has checked itself. A failure of a per-condition indicate a bug in the caller, and routines have these asserts to help find errors in the caller. The post conditions are the things the routine promises to deliver, a failure of a post condition indicates a bug in this routine. One part of asserts is there presence documents what the routines pre- and post-conditions are (in addition to their debugging help) Many of these tests are trivial (thing like simple tests on values) and for these the removal may not matter that much (but sometimes a 1% gain is important, maybe not so much in Python though). Some of the tests may be very expensive, test like 'tree is balanced' or 'list has no duplicate values' may require more work to verify then the routine itself, and these can be important to remove in production releases. For the 'cheap' asserts, if you want to keep the test in the code because you aren't sure you have debugged enough, you can replace the assert with an if, with the assert statement in the conditional (or just raise the exception yourself, or better use a custom problem report routine). The normal reason to not want to do this is that the asserts output isn't really friendly to the average user, but is designed for the developer. In some cases, it might even reveal information that the end user isn't really supposed to know. -- Richard Damon _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/Q4DHIKGZW6P6YVTONUAURYPM2H4VJMHT/ Code of Conduct: http://python.org/psf/codeofconduct/
