What does Python's `assert` statement do, and what happens to it under `python -O`?

### `assert` is a statement, not a function `assert` belongs to Python's grammar in the same family as `raise`, `return` and `del`. It takes one or two comma-separated expressions: the condition, and an optional failure message. It has no argument list of its own, which is why writing it as if it were a call is a real bug rather than a style nit. The compiler expands `assert expr, msg` into roughly this: ```python if __debug__: if not expr: raise AssertionError(msg) ``` Three things follow straight from that expansion. The condition is put through the ordinary truthiness test, so any object works, not just a `bool`. The message operand is evaluated *only* when the condition is falsy, so an expensive f-string message costs nothing on the happy path. And every part of it sits under `__debug__`. ### `__debug__` is a compile-time constant `__debug__` is a builtin name the compiler treats specially. You cannot rebind it — `__debug__ = False` is a `SyntaxError: cannot assign to __debug__` — and its value is fixed when the interpreter starts. In a normal run it is `True`. Start the interpreter with `-O`, or with the environment variable `PYTHONOPTIMIZE` set to a non-empty value, and it is `False`. Because the compiler knows the constant statically, it then emits **no bytecode at all** for the assert statement: the condition is never evaluated, the message is never built, and no branch is taken at runtime. This is removal at compile time, not a runtime check that quietly returns. `sys.flags.optimize` reports the level a process is running at: `0` for a normal run, `1` for `-O`, `2` for `-OO`. Both `__debug__` and that flag are readable from inside the program, which is the only reliable way to find out what a deployed process actually did. Bytecode caching follows the same split: an optimized run reads and writes a separately tagged cache file, carrying an `opt-1` tag alongside the ordinary one, so an interpreter started with `-O` never picks up cached bytecode that still contains the assertions. ### Why this makes `assert` a developer-only tool The optimize level is a property of the *deployment*, not of the source. A base container image, a platform default, a CI job or an operator's habit can set `PYTHONOPTIMIZE` without anyone touching your code, and every assertion in the process — yours and every library's — disappears together. So the honest rule is: * **`assert` states something that is true unless your own code has a bug.** Internal invariants, post-conditions, "this cache and this recomputed value must agree", "this branch is unreachable". Losing the check under `-O` loses a diagnostic, not a guarantee. * **`raise` states something that may be false because the outside world is not what you hoped.** Argument validation on a public function, parsed input from a file or a request, permission checks, configuration sanity. Those must be `if not cond: raise SomeError(...)` with a domain-appropriate exception type. The failure mode of getting this backwards is nasty precisely because it is silent: the code behaves identically in development, and in production the check is simply not there. ### Side effects inside an assertion Because the whole statement can vanish, anything with a side effect inside the asserted expression vanishes with it. A line that both consumes an item and checks it will consume nothing under `-O`, and the bug shows up as missing work rather than as a failed assertion. Keep asserted expressions pure and cheap. ### `AssertionError` in an exception hierarchy `AssertionError` derives from `Exception`, so a broad `except Exception:` handler catches it exactly like anything else. That is how a service ends up swallowing its own invariant failures and logging them as a generic error. It is also why `AssertionError` is a poor exception type to expose at an API boundary: to a reader it says "this program has a bug", not "your input was invalid", and a caller has no way to distinguish the two. ### What interviewers are actually testing The question is a proxy for a design instinct. A candidate who says "`assert` raises `AssertionError` when the expression is falsy" has answered half of it. The other half — that a command-line flag or an environment variable can delete the statement before it ever runs, and that this is what disqualifies `assert` from doing any job the program depends on — is the part that separates someone who has only written asserts in a scratch script from someone who has reasoned about what runs in production.