Re: [Pyunit-interest] comments on PyUnit

[Chuck E. <ec...@mi...>]

At 12:26 PM 4/11/2001 -0500, Guido van Rossum wrote:
>And that's exactly what I'm strongly opposing.  When "python -O" is
>used, tests that use the assert statement will not be performed
>correctly, because no code is compiled for assert statements in that
>case.  It's a nasty trap to fall into, and the fact that the PyUnit
>framework uses AssertionError makes it a common mistake.

But isn't this the real problem?

I had an advanced application a few years back in Objective-C, where GNU 
optimizations and macro assertions were 2 separate deals. At one point, I 
compiled with assertions off and tested the program. The gain in 
performance was 0.5% so I decided to ship the product to customers with 
optimization as well as assertions. Even if it had been 10%, I still would 
have kept assertions.

The reason to keep assertions is that they raise exceptions which can then 
be caught and dealt with appropriately, such as notifying customer support, 
or skipping the processing of a troubled object within a larger set of objects.

The alternative is that the program keeps chugging through an erroneous 
situation. It's doubtful that you covered that in your testing and that you 
know what the results will be. What's even more doubtful is that anything 
intelligent will happen past the point where the "missing assertion" was 
located.

Also, it shouldn't be surprising that assertions don't slow software down 
by much. Your algorithms and caching and such are what's most important. 
Assertions pretty much ride along with your processing as extra 
instructions, not necessarily extra complexity.

Finally, consider the flip side: Is there any reason to give to developers 
that their assertions MUST be disabled for optimization?


-Chuck