To verify program invariants and assumptions during development and testing.

To document and enforce assumptions about program state, making them explicit to readers and triggering an error when violated.

When you need to confirm that a precondition, postcondition, or invariant holds during development or testing.

Used in debugging, testing, defensive programming, and as lightweight contracts in Python code.

assert condition[, message]

assert condition [, message]

condition: bool expression, message: str optional

• isinstance
• len
• ==
• !=
• <
• >
• hasattr
• raise AssertionError

• raise AssertionError(message) if not condition
• if not condition: raise ValueError(message)
• using assert for debugging only
• not for production error handling.

1. Using assert for argument validation in production code – cause: belief that assert cannot be disabled; consequence: validation disabled when Python is run with -O, leading to silent failures. 2. Forgetting that assert raises AssertionError, not a custom exception – cause: expecting a specific exception type; consequence: incorrect exception handling. 3. Placing side‑effects inside the assert condition – cause: side effects disappear when asserts are disabled; consequence: logic errors in optimized runs. 4. Supplying a non‑string message that raises its own exception – cause: message evaluation fails; consequence: masking the original assertion failure. 5. Writing assert with a tuple that is always truthy – cause: misunderstanding that assert checks tuple truthiness; consequence: silent failure.

raise Exception vs assert – raise always executes, assert can be disabled with -O; if not condition: raise ValueError vs assert condition – explicit exception vs automatic AssertionError; using pytest.raises vs assert for testing – explicit context manager vs simple assertion.

Coming from Java/C: using assert for argument validation – in Python assertions can be disabled with -O, so use explicit raise instead. Coming from C: using assert only for debugging – same warning applies; avoid relying on asserts for production checks.

• assert statement
• debugging assertions
• defensive programming

1. Do not use assert for runtime error handling in production because it can be disabled; 2. Assert evaluation has negligible overhead when enabled but is completely removed with -O, so no runtime cost in optimized builds; 3. The condition must be free of side effects, otherwise disabling assert changes program behavior.

Using assert correctly catches logical errors early during development, making bugs easier to find and preventing silent failures in debug builds.

Think of assert as a vigilant guard who checks that a door is locked; if the door is open, the guard raises an alarm immediately, but if the guard is told to stand down (‑O), the alarm never sounds.

The assert statement is intended for debugging and internal consistency checks; it is not a substitute for proper error handling in user‑facing code.