When should I use assert in a small Python program?

Use assert as a debugging check for an assumption your code expects to hold. For example, after your program’s logic selects an item from an internal list, an assertion could check that the result is not None if that should be guaranteed by the earlier steps.

The idea is: “This should already be true if my program’s logic is working.” Assertions are not a general-purpose way to reject bad input. Python may omit them when run with optimization (-O), so they cannot guarantee that a check happens on every run. [S1]

Ask whether the check is a rule the program must enforce. If a negative count must be rejected, use an explicit condition and raise an appropriate exception:

if count < 0:
    raise ValueError("count must be zero or greater")

That makes the check part of the program’s normal logic. By contrast, an assertion is suited to an internal assumption: a condition that should follow from earlier steps in your code. The Python reference cautions against assertions for checks that must always execute, including user-input validation. [S1]

Suppose a function receives a count from outside the function. The function needs to enforce its input rule explicitly:

def make_labels(count):
    if count < 0:
        raise ValueError("count must be zero or greater")
    return [f"Item {number}" for number in range(count)]

Now suppose a later internal step should only be reached with a nonnegative count because earlier logic has already checked it. An assertion could document that expectation:

assert count >= 0, "internal count should be nonnegative"

These are not interchangeable guarantees. The explicit exception check enforces the input rule. The assertion checks an internal assumption, and optimization may omit it. Don’t make correctness depend on that assertion being present. [S1]

A useful distinction is: is a failed check an invalid request the program must handle, or an unexpected result from its own logic? The first calls for explicit validation; the second may be a good fit for an assertion.

Use this checklist:

1. Must the check happen on every run? Use an explicit condition and raise an appropriate exception if it fails.
2. Does the value come from outside your program? Validate it explicitly according to the rules your program must enforce.
3. Is this an assumption about internal state? If it should follow from earlier logic, an assertion may help flag a programming mistake during development.
4. Would omitting the check make the program violate a required rule? Don’t rely on assert; optimization may omit assertions. [S1]
5. Will the failure be understandable? Choose an appropriate exception for required validation, or add a short message to an assertion when it would clarify the failed assumption.

For a small program, keep the distinction simple: explicitly reject inputs that violate required rules; reserve assertions for internal expectations. [S1]