On 2009-07-02, Paul Rubin <http> wrote: > Tim Harig <user...@ilthio.net> writes: >> 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 >> That way an exception will be raised if there is an error somewhere else >> in the code rather then silently passing a possibly incorrect value. > Well, that assert is not right because you have to handle the case > where one of the values is None. The general sentiment is reasonable > though, if you're concerned that the precondition may not be valid.
Sorry, it worked under 2.5: 2.5 >>> lower = None 2.5 >>> higher = 10 2.5 >>> assert lower <= higher 2.5 >>> assert higher < lower 2.5 Traceback (most recent call last): 2.5 File "<stdin>", line 1, in <module> 2.5 AssertionError 2.5 >>> higher = -10 2.5 >>> assert lower <= higher 2.5 >>> assert higher < lower 2.5 Traceback (most recent call last): 2.5 File "<stdin>", line 1, in <module> 2.5 AssertionError None seems to have been evaluated less then any integer. The same isn't true under 3.0: 3.0 >>> lower = None 3.0 >>> higher = 10 3.0 >>> assert lower <= higher 3.0 Traceback (most recent call last): 3.0 File "<stdin>", line 1, in <module> 3.0 TypeError: unorderable types: NoneType() <= int() Then it is probably easier to just handle it in the conditionals and raise an exception manually. -- http://mail.python.org/mailman/listinfo/python-list
