(It's also acceptable to use assert when testing code, as a sort of quick-and-dirty poor man's unit testing, so long as you accept that the tests simply won't do anything if you run with the -O flag. And I sometimes use "assert False" in code to mark code branches that haven't been written yet, and I want them to fail. Although "raise NotImplementedError" is probably better for that, if a little more verbose.)
Opinions on assertions vary, because they can be a statement of confidence about the correctness of the code. If you're certain that the code is correct, then assertions are pointless, since they will never fail and you can safely remove them. If you're certain the checks can fail (e.g. when testing input data provided by the user), then you dare
not use assert since it may be compiled away and then your checks will be skipped.
It's the situations in between those two that are interesting, times when you're certain the code is correct but not *quite* absolutely certain. Perhaps you've missed some odd corner case (we're all only human). In this case an extra runtime check helps reassure you that any errors will be caught as early as possible rather than in distant parts of the code.
(This is why assert can be divisive. Since we vary in our confidence about the correctness of code, one person's useful assert is another person's useless runtime test.)
Another good use for asserts is checking program invariants. An invariant is some condition which you can rely on to be true unless a bug causes it to become false. If there's a bug, better to find out as early as possible, so we make a test for it, but we don't want to slow the code down with such tests. Hence assert, which can be turned on in development and off in production.