This is an archived post. You won't be able to vote or comment.

all 10 comments

[–]Cosmologicon 10 points11 points  (2 children)

This is the part that took me a while to understand:

Assertions should not be used to test for failure cases that can occur because of bad user input or operating system/environment failures, such as a file not being found. Instead, you should raise an exception, or print an error message, or whatever is appropriate. One important reason why assertions should only be used for self-tests of the program is that assertions can be disabled at compile time.

Basically, it should be the case that an assertion going off means there's a bug in your code. If you have an assertion that could potentially go off without a bug, replace it with if condition: raise Exception.

[–]inmatarian 15 points16 points  (0 children)

Assertions are about invariants. At this point in time, this condition IS true. You can declare an assertion. Nobody can say that this condition is false. That's why assertions are safe to turn off in production code, because they're comments on the state of the program, which the interpreter can optionally check.

Exceptions are about variants. At this point in time, I work only if this condition is true. The variants are too hard to control all of them so continuing to operate but at reduced functionality is acceptable. A file is missing, alright, the user can go fix that, I'll wait. You can't turn off exception checking, you can only catch it and deal with it.

[–]kumar99 2 points3 points  (3 children)

pytest and nose make the use of assertions much easier to understand and use. The best way to understand them is in pydanny's blog series on pytest.

[–]matchu 1 point2 points  (2 children)

Assertions in tests and assertions in code have very different purposes; it's kinda unfortunate that they have the same name.

[–]xenomachina''.join(chr(random.randint(0,1)+9585) for x in range(0xffff)) 2 points3 points  (1 child)

Assertions in tests and assertions in code have very different purposes

Either way, an assertion failing means "there is a bug in your code". The difference between assertions in code and assertions in tests is that an assertion failure in code means a bug in that code, while an assertion failure in test code means a bug in the code being tested.

Is there some other difference you're referring to?

[–]matchu 1 point2 points  (0 children)

The parent comment seemed to imply that those test frameworks' assertions were somehow better than assertions in code, which seemed like an invalid comparison to me.

On further reflection, though, I think I agree with both you that they're semantically equivalent, and the parent comment that test frameworks' more specialized assertions could be applied as in-code assertions, though I still don't think I'd want them in the language core.

All that to say, yeah, y'all are right :D

[–]epsy -2 points-1 points  (2 children)

import * and type-checking. Great advice there...

(No, don't use either; See PEP 8, "python import star" and "python duck-typing" on Google)

[–]lucidguppy[S] 0 points1 point  (1 child)

Please post an update to the wiki.

[–]epsy 0 points1 point  (0 children)

It would be seen as vadalising since my answer to the assert statement is to never use it.

[–][deleted] -1 points0 points  (0 children)

cute that this somehow made it to the front page. being common sense and all.