Assertions
alister
alister.ware at ntlworld.com
Fri Sep 22 06:50:43 EDT 2017
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.
More information about the Python-list
mailing list