Assertions

[alister]

On Fri, 22 Sep 2017 03:44:59 +1000, Steve D'Aprano wrote:

> On Fri, 22 Sep 2017 02:29 am, Tobiah wrote:
> 
>> Are these completely equivalent?
>> 
>> def foo(thing):
>> 
>>         assert(thing > 0), "Thing must be greater than zero"
>> 
>> 
>> def foo(thing):
>> 
>>         if not (thing > 0): raise AssertionError("Thing must be greater
>>         than zero")
>> 
>> 
>> Other than the fact that the assertion can be turned off with -O?
> 
> As I replied to Ned just now, the two may compile to slightly different
> byte-code. But (apart from the -O optimization) they ought to be
> semantically the same, as far as the interpreter goes. I'd be very
> surprised if the byte-code differences were ever more than trivial.
> 
> But I don't think they are the same as far as the human reader goes. If
> you believe the truism that code is written for other people, and only
> incidentally to be run by computers, then I think we should say that the
> two above are very different.
> 
> The first is an actual assertion. It has to be an assertion, because it
> uses the assert keyword!
> 
> The second is testing a condition, and if need be, raising an exception.
> Which looks like an inappropriate exception. Why AssertionError? It
> looks like it ought to be a ValueError.
> 
> Assertions aren't merely a synonym for testing a condition and raising
> an exception if the condition fails. Assertions have semantics to the
> human reader. I wrote a blog post explaining why you should use
> assertions:
> 
> - you want a checked comment;
> - you have code that can't possibly fail, unless it does;
> - you are testing the program logic;
> - you are checking a contract;
> 
> and when you should not. By using `assert`, you are signalling your
> intent to do one of the above.
> 
> http://import-that.dreamwidth.org/676.html
> 
> But by using an ordinary `if ... raise AssertionError`, the intention is
> ambiguous. If you meant for it to be an assertion, why not use assert?
> If it is not an assertion, then AssertionError is probably the wrong
> exception.
> 
> (It is okay in a testing framework, like unittest, but a bad idea in a
> regular library or an application. Your end-users should never see an
> AssertionError.)
> 
> 
> The bottom line is, if I saw
> 
>     if not (thing > 0): raise AssertionError(...)
> 
> in a code review, I'd probably insist that either it be changed to use
> `assert`,
> or the exception be changed to ValueError, whichever better expresses
> the intention of the code.

In a code review I would want the condition changed to be less noisy/
confusing to the reader.

if thing <=0: whatever




-- 
The best thing about growing older is that it takes such a long time.