Which built-in Python values are falsy inside an `if` statement?

## Truthiness is a two-question rule Every `if`, `while`, `not`, `and`, `or`, filter predicate and `assert` in Python asks the same question of a value: *is this object truthy?* Python never requires the object to be `True`. It asks the object to summarise itself as one bit, and unless the object says otherwise, the answer is "yes, I am truthy". That default matters. **An arbitrary object is truthy**; falsiness is the exception a small, memorisable set of built-ins opts into. `bool(x)` is the explicit spelling of the same question, and `if x:` is exactly `if bool(x):` with the conversion done inline by the interpreter. ## The complete built-in falsy set Learn it as three groups rather than as a list of eleven items: 1. **The two constants** — `None` and `False`. 2. **Zero of every numeric type** — `0`, `0.0`, `-0.0`, `0j`, and `decimal.Decimal("0")` or `fractions.Fraction(0, 5)` for the stdlib numeric types. 3. **Every empty container or sequence** — `""`, `b""`, `[]`, `()`, `{}`, `set()`, `frozenset()`, `range(0)`, and an empty `bytearray`, `dict` view or `collections.deque`. ```python falsy = [None, False, 0, 0.0, 0j, "", b"", [], (), {}, set(), range(0)] assert not any(falsy) ``` Anything not in those groups is truthy, and that includes several values people expect to be falsy: the strings `"0"`, `"False"` and `" "` are all non-empty, so all three are truthy. The list `[0]` and the dict `{"k": None}` are truthy too — they are *containers with one element*, and the falsiness of what they contain is irrelevant. Container truthiness is about length, never about contents. ## Zero is not None, and empty is not missing The single most valuable consequence is that **truthiness collapses distinctions your program may care about.** `if x:` treats `0`, `0.0`, `""`, `[]`, `{}` and `None` identically. When a field's domain includes a legitimate zero or a legitimate empty string — a count, a price, a retry budget, a user-supplied comment, a percentile threshold — `if x:` is asking the wrong question. The precise question is `if x is not None:`, which asks only whether the value is absent and lets `0` and `""` through as real data. The mirror image is just as common: reading configuration or environment values as text. An environment variable set to the string `"0"` or `"false"` is a non-empty `str` and therefore truthy, so `if os.environ.get("FEATURE"):` turns the feature *on* for someone who explicitly set it to `0`. The fix is to compare or parse the text deliberately rather than to lean on truthiness. ## `not` always hands back a real `bool` `not x` evaluates the truthiness of `x` and returns the opposite as an actual `bool` object — `True` or `False`, never the operand. That makes `not` different from `and` and `or`, which return one of their operands unchanged. So `not []` is `True` (type `bool`), while `[] or "z"` is the string `"z"`. `not not x` is therefore a working, if unidiomatic, coercion to `bool`; the readable spelling is `bool(x)`, and `operator.truth(x)` is the same conversion as a function you can pass around. Because `if` performs the conversion itself, writing `if bool(x):`, `if x == True:` or `if len(x) > 0:` adds no correctness and loses idiom. `if x == True:` is actively worse: it tests equality against the `True` object, so a truthy value such as `2` or `"yes"` fails the test even though `if x:` would have accepted it. ## Where the values come from Built-in falsiness is not hard-coded per type in the `if` statement. The interpreter asks the object's own type: a type may define `__bool__` to answer directly, or `__len__`, in which case length zero means falsy. That is why every empty container in the standard library is falsy without any of them being special-cased — they all report their length. (Designing those methods for your own classes is a separate subject; what matters here is that the built-in behaviour you rely on is uniform and predictable.) ## One historical wrinkle worth knowing `datetime.time(0, 0)` — midnight — was falsy in very old Python because it was treated as a "zero" time. That was fixed in **Python 3.5**: all `datetime.time` instances are truthy, and on **3.14** `bool(datetime.time(0, 0))` is `True`. It is a good illustration that "zero-like means falsy" is a convention each type chooses, not a law, and that guessing at a type's truthiness instead of checking it is how subtle bugs get written. The rest of the rules above are stable: the built-in falsy set has not changed through **3.14**, and nothing in the deferred-annotation, free-threading or interpreter work of recent releases touches it.