On 2009-07-03, Steven D'Aprano <st...@remove-this-cybersource.com.au> wrote: > On Thu, 02 Jul 2009 22:14:18 +0000, Tim Harig wrote: >> On 2009-07-02, Paul Rubin <http> wrote: >>> Tim Harig <user...@ilthio.net> writes: >>>> If lower is 5 and higher is 3, then it returns 3 because 3 != None in >>>> the first if. >>> Sorry, the presumption was that lower <= higher, i.e. the comparison >>> had already been made and the invariant was enforced by the class >>> constructor. The comment should have been more explicit, I guess. >> That being the case, it might be a good idea either to handle the >> situation and raise an exception or add: >> assert self.lower <= self.higher > Only if you want strange and mysterious bugs whenever somebody runs your > code with the -O flag.
The point here is that Rubin presumed that the condition where lower > higher should never exist. Therefore, because the program given segment of program doesn't test it elswhere, it is possible that a bug in the code that sets lower > higher could go unoticed while silently passing the wrong data. Therefore, It is better to test that assumption in a way that *will* crash if something is wrong, for instance, if another method accidently changes one of the values. That would tend to make errors in another method of the class (or even higher up in this method), more likely to be found. > asserts are disabled when the -O flag is given. Right, like defining NDEBUG in C. In _Writing Solid Code_ by Steve Maguire, he likens it to having two pieces of code: one for testing where any errors should cause crashes as early as possible and one for shipping where it may be better to handle errors if possible from within the code. > You should never use asserts for testing data. That's not what they're > for. They're for testing program logic (and unit-testing). What I am suggesting here is exactly that. If lower is always defined such that it should always be equal to or lower then higher, then there is an error in the code somewhere if lower is higher by the time this code is called. Either the constructor didn't didn't reject input properly or another method within the class has inadvertantly changed higher or lower in an uncorrect way. In any event, whether I am using it 100% correctly, I want to find any errors in my code. If there is an error, I want the program to crash during testing rather then silently passing bad data. assert will help here. Unfortunatly, Rubin is right. I did make the mistake that the assert will fail with higher or lower values of None, which is allowed here. The same basic premise is correct but will require more complex assertions to allow that through. -- http://mail.python.org/mailman/listinfo/python-list
