Why does `assert (total == 0, 'total must be zero')` never fail in Python?

### What the parentheses actually build `assert` is a statement, so it never takes an argument list. When you write ```python assert (total == 0, 'total must be zero') ``` the parentheses are not a call; they are a tuple display. The statement receives a **single** expression — the two-element tuple `(False, 'total must be zero')` — and no message operand at all. A tuple is truthy when it is non-empty, and this one always has two elements, so the condition is `True` on every run, for every value of `total`. The assertion can never fail. Worse, it looks like the most carefully written assertion in the file, because it has a message. The subtlety is that the truth value of the tuple has nothing to do with the truth value of its first element. `bool(())` is `False`; `bool((False,))` is `True`; `bool((False, 'anything'))` is `True`. The container is what gets tested. ### The compiler does warn CPython's compiler recognises the shape and emits a warning at compile time: ``` SyntaxWarning: assertion is always true, perhaps remove parentheses? ``` That is a `SyntaxWarning`, not a `SyntaxError`, so the module still imports and the program still runs. Two practical consequences: the warning goes to standard error at *compile* time, which for an imported module means the first time it is compiled — once the bytecode cache is warm you may never see it again; and a warning filter that hides warnings, or a service whose standard error nobody reads, hides it completely. Treating warnings as errors during a test run, or running any linter that carries this rule, catches it deterministically where the eye does not. The warning only fires for a literal tuple written inline. Assert a name that happens to hold a non-empty tuple and the compiler has nothing to go on, so it stays silent. ### Not every parenthesis is wrong `assert (total == 0)` is fine — that is a redundant grouping around one expression, not a tuple, and it behaves identically to the unparenthesised form. The bug appears the moment a comma joins the message inside the same parentheses, which is exactly what muscle memory from a language where assertions are function calls produces. For a long condition or a long message, wrap without creating a tuple: ```python assert ( total == 0 ), 'total must be zero' assert total == 0, ( 'total must be zero, got a mismatch between the parsed rows ' 'and the recomputed sum' ) ``` The first parenthesises only the condition; the second parenthesises only the message, where adjacent string literals concatenate. Either is safe; what is unsafe is one pair of parentheses containing the comma that separates condition from message. ### The neighbouring mistake The other way people try to attach a message is ```python assert total == 0 and 'total must be zero' ``` which does not raise a `SyntaxWarning` and is not always true — but it has no message either: on failure you get a bare `AssertionError`, and when the condition holds, the `and` expression evaluates to a truthy string, which is merely confusing. ### Why the bug survives so long This defect is invisible in every way a team normally notices things. Tests pass, because the assertion never fails. Code review reads it as correct English. Coverage shows the line executed. There is no exception, no log line, no latency change. It is discovered only when someone finally breaks the invariant on purpose and nothing happens, or when a reader looks hard at the syntax. It also compounds with the `-O` behaviour of assertions: a team may believe a whole family of checks is guarding them when one subset was compiled out by an optimize flag and another subset was never capable of firing in the first place. Both failures are silent, and neither is visible in the diff that introduced it. ### How to answer it in the room State the mechanism, not the rule of thumb: `assert` is a statement, the parentheses form a tuple, a non-empty tuple is truthy, so the assertion is a no-op that still costs a truth test. Then show the correct form and mention that CPython emits a `SyntaxWarning` for it, and that a linter or warnings-as-errors in the test run is what keeps it out of the codebase.