{"title":"any & all","description":"","content":"`any` and `all` are two small built-ins that answer two very common questions about a collection: \"is at least one of these true?\" and \"are all of these true?\". They read like English, short-circuit as soon as they have an answer, and pair beautifully with generator expressions. This lesson covers what they return, the surprising case of an empty iterable, and how to write validation checks that are both fast and readable.\n\n---\n\n# What any and all Actually Do\n\nBoth functions take a single iterable and return a boolean. `any` returns `True` if at least one element is truthy, and `False` if every element is falsy. `all` returns `True` if every element is truthy, and `False` if at least one element is falsy.\n\n\n```python\n>>> any([False, False, True])\nTrue\n>>> any([False, False, False])\nFalse\n>>> all([True, True, True])\nTrue\n>>> all([True, False, True])\nFalse\n```\n\n\nThe elements don't have to be booleans. Anything Python can evaluate for truthiness works, so you can drop in numbers, strings, lists, or objects. These values are falsy: `0`, `0.0`, `\"\"`, `None`, `[]`, `{}`, `set()`, and `False`. Everything else is truthy.\n\n\n```python\nin_stock_counts = [0, 0, 5, 0]\nprint(any(in_stock_counts)) # 5 is truthy\nprint(all(in_stock_counts)) # zeros are falsy\n```\n\n\nThis is the simplest form. The real power shows up when you pair these with a generator expression that produces booleans from a richer input, which we'll get to in a moment.\n\n---\n\n# The Empty Iterable Trap\n\nHere's the one rule that trips up almost everyone the first time they meet these functions.\n\n\n```python\n>>> any([])\nFalse\n>>> all([])\nTrue\n```\n\n\n`any([])` returning `False` feels intuitive. There's nothing in there, so nothing is true. Fine.\n\n`all([])` returning `True` is the surprise. Even with no elements, `all` says yes.\n\nThis is called **vacuous truth**. The rule for `all` is \"every element satisfies the condition\". If there are no elements, there are no elements that *fail* to satisfy the condition, so the rule technically holds. Python is being a strict logician here. The same idea shows up in math: a statement of the form \"for every x in the empty set, P(x) holds\" is always true because there's no counterexample to find.\n\nThis matters in real code. A common pattern is to validate every item in a cart:\n\n\n```python\ncart = []\nall_in_stock = all(item[\"stock\"] > 0 for item in cart)\nprint(f\"All items in stock: {all_in_stock}\")\n```\n\n\nAn empty cart is reported as having all items in stock. If your business logic depends on the cart actually containing something, you have to check that separately.\n\n\n```python\ncart = []\n\nif cart and all(item[\"stock\"] > 0 for item in cart):\n print(\"Ready to check out\")\nelse:\n print(\"Cart is empty or has out-of-stock items\")\n```\n\n\nThe `cart and ...` short-circuits when the cart is empty, so `all` never even runs in that case. This is the safe pattern for any \"must have at least one item AND every item must satisfy something\" check.\n\n---\n\n# Pairing with Generator Expressions\n\nYou almost never call `any` or `all` on a literal list of booleans. The real use is pairing them with a generator expression that turns each element into a boolean on the fly. Generator expressions look like list comprehensions but use parentheses and produce one value at a time.\n\n\n```python\nprices = [29.99, 14.99, 9.99, 49.99, 19.99]\n\nhas_expensive = any(price > 40 for price in prices)\nall_affordable = all(price < 100 for price in prices)\n\nprint(f\"Has an expensive item: {has_expensive}\")\nprint(f\"Everything affordable: {all_affordable}\")\n```\n\n\nThe expression `price > 40 for price in prices` yields `False, False, False, True, False`. As soon as `any` sees the first `True`, it stops and returns. We'll come back to that \"stops\" part below.\n\nWhen the inputs are richer objects, generator expressions let you reach into them cleanly:\n\n\n```python\ncart = [\n {\"name\": \"Wireless Mouse\", \"price\": 19.99, \"stock\": 12, \"shipped\": True},\n {\"name\": \"USB Cable\", \"price\": 4.99, \"stock\": 0, \"shipped\": True},\n {\"name\": \"HDMI Cable\", \"price\": 8.99, \"stock\": 4, \"shipped\": False},\n]\n\nany_out_of_stock = any(item[\"stock\"] == 0 for item in cart)\nall_shipped = all(item[\"shipped\"] for item in cart)\n\nprint(f\"Any item out of stock: {any_out_of_stock}\")\nprint(f\"All items shipped: {all_shipped}\")\n```\n\n\nTwo readable lines that each answer a complete business question. Without `any` and `all`, you'd write a loop with a flag variable and an early `break`, and the result would be longer and noisier.\n\n\n> **INFO**\n>\n> **Cost:** Always prefer a generator expression over a list comprehension inside `any` and `all`. `any([item[\"stock\"] == 0 for item in cart])` builds the entire list first, then walks it. The generator form `any(item[\"stock\"] == 0 for item in cart)` walks the cart lazily and stops at the first hit. For a 10,000-item cart where the first item is out of stock, the generator form does one check; the list-comprehension form does 10,000.\n\n\n---\n\n# Short-Circuit Evaluation\n\nBoth functions stop as soon as they can answer the question. `any` stops at the first truthy element. `all` stops at the first falsy element. This is called short-circuit evaluation, and it's the same idea you've seen with the `and` and `or` operators.\n\n\n```mermaid\nflowchart LR\n START[Start iterating]:::orange --> CHECK{Next element?}:::cyan\n CHECK -->|No more| EMPTY[any returns False
all returns True]:::teal\n CHECK -->|Got one| EVAL{Element
truthy?}:::cyan\n EVAL -->|Truthy| ANYHIT[any returns True
and stops]:::green\n EVAL -->|Truthy| ALLNEXT[all continues
to next element]:::teal\n EVAL -->|Falsy| ANYNEXT[any continues
to next element]:::teal\n EVAL -->|Falsy| ALLHIT[all returns False
and stops]:::red\n\n ANYNEXT --> CHECK\n ALLNEXT --> CHECK\n\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe diagram shows the decision flow. Each element is checked one at a time, and the function bails out the moment the result is decided. `any` wins on a truthy element; `all` wins on a falsy element.\n\nYou can see this clearly with a generator that prints as it yields:\n\n\n```python\ndef stock_for(product):\n print(f\"Checking {product}\")\n return {\"Mouse\": 5, \"Cable\": 0, \"Charger\": 8}[product]\n\ncart = [\"Mouse\", \"Cable\", \"Charger\"]\nprint(any(stock_for(item) == 0 for item in cart))\n```\n\n\n`any` checks the Mouse, sees stock 5 (truthy but the condition `== 0` is False, so it keeps going), then checks the Cable, sees stock 0 which makes the condition True, returns immediately. The Charger is never inspected. This is the whole point: you get the answer with the minimum amount of work.\n\nThe same logic applies to `all`, just inverted:\n\n\n```python\nprint(all(stock_for(item) > 0 for item in cart))\n```\n\n\nThe Mouse passes (stock 5 > 0), the Cable fails (stock 0 > 0 is False), and `all` returns `False` without ever checking the Charger.\n\n\n> **INFO**\n>\n> **Cost:** Short-circuiting is why these functions are cheap for huge iterables when the answer is decided early. For 1 million items where the first one fails an `all` check, `all` does one comparison and stops. The cost scales with how far in the answer is, not the total size.\n\n\n---\n\n# Common Patterns\n\nThese two functions cover a small number of patterns that come up constantly.\n\n**Pattern 1: \"Does at least one match?\"**\n\n\n```python\nproducts = [\n {\"name\": \"Mouse\", \"category\": \"electronics\", \"discount\": 0},\n {\"name\": \"Cable\", \"category\": \"electronics\", \"discount\": 15},\n {\"name\": \"Notebook\", \"category\": \"stationery\", \"discount\": 0},\n]\n\nhas_discount = any(p[\"discount\"] > 0 for p in products)\nprint(f\"Has a discounted item: {has_discount}\")\n```\n\n\n**Pattern 2: \"Do all of them match?\"**\n\n\n```python\norder_items = [\n {\"name\": \"Mouse\", \"shipped\": True},\n {\"name\": \"Cable\", \"shipped\": True},\n {\"name\": \"Charger\", \"shipped\": True},\n]\n\nready_to_close = all(item[\"shipped\"] for item in order_items)\nprint(f\"Order ready to close: {ready_to_close}\")\n```\n\n\n**Pattern 3: Input validation**\n\n\n```python\ndef is_valid_email(email: str) -> bool:\n return \"@\" in email and \".\" in email.split(\"@\")[-1]\n\nemails = [\"alice@example.com\", \"bob@store.io\", \"charlie@example.com\"]\nall_valid = all(is_valid_email(e) for e in emails)\nprint(f\"All emails valid: {all_valid}\")\n```\n\n\n**Pattern 4: Existence check across multiple conditions**\n\nYou can stack conditions inside the expression itself:\n\n\n```python\ncart = [\n {\"name\": \"Wireless Mouse\", \"price\": 19.99, \"stock\": 12},\n {\"name\": \"USB Cable\", \"price\": 4.99, \"stock\": 50},\n {\"name\": \"HDMI Cable\", \"price\": 8.99, \"stock\": 4},\n]\n\nhas_cheap_low_stock = any(item[\"price\"] < 10 and item[\"stock\"] < 10 for item in cart)\nprint(f\"Has cheap, low-stock item: {has_cheap_low_stock}\")\n```\n\n\nThe HDMI Cable matches both conditions, so `any` returns `True` after the third element. The generator only had to look at three items.\n\n**Pattern 5: Comparing two collections**\n\n`any` and `all` work over any iterable, including the result of `zip`:\n\n\n```python\nexpected = [29.99, 14.99, 9.99]\nactual = [29.99, 14.99, 9.99]\n\nall_match = all(a == b for a, b in zip(expected, actual))\nprint(f\"Prices match: {all_match}\")\n```\n\n\n---\n\n# The De Morgan Swap\n\nThere's a useful equivalence from logic that comes up when you write these checks. The statement \"no items are out of stock\" can be written two ways:\n\n\n```python\ncart = [\n {\"name\": \"Mouse\", \"stock\": 5},\n {\"name\": \"Cable\", \"stock\": 3},\n {\"name\": \"Charger\", \"stock\": 8},\n]\n\n# Way 1: not any\nno_out_of_stock_v1 = not any(item[\"stock\"] == 0 for item in cart)\n\n# Way 2: all not\nno_out_of_stock_v2 = all(item[\"stock\"] != 0 for item in cart)\n\nprint(no_out_of_stock_v1, no_out_of_stock_v2)\n```\n\n\nBoth produce the same answer. Mathematically, this is De Morgan's law: \"not (any x is bad)\" equals \"all x are not bad\".\n\nSo which one should you write? Pick whichever reads better in context. A loose rule:\n\n\n| Question you're answering | Reads better as |\n| ------------------------- | --------------- |\n| Is there even one bad item? | `any(is_bad(x) for x in items)` |\n| Are all items good? | `all(is_good(x) for x in items)` |\n| Are zero bad items present? | `not any(is_bad(x) for x in items)` |\n| Is the cart entirely free of zeros? | `all(stock > 0 for stock in stocks)` |\n\n\nWhen the natural English version contains \"no\" or \"none\", `not any` often sounds closer to the spoken form. When it's \"every\" or \"all\", `all` is the obvious choice. If you find yourself writing `all(not ...)`, take a second look, `not any(...)` is usually clearer.\n\n\n> **INFO**\n>\n> **Cost:** Both forms have the same short-circuit behavior. `not any` stops at the first match. `all not` stops at the first non-match. They do the same work in the same order, so pick on readability, not performance.\n\n\n---\n\n# Putting It Together\n\n`any` and `all` are simple, but they let you replace whole loops with a single readable expression. Their combination of generator-expression syntax and short-circuit evaluation makes them efficient even on large inputs, and they pair naturally with the e-commerce checks you write all the time: stock validation, order status, review filters, price thresholds.\n\nThe two things to keep in your head: vacuous truth (`all([]) == True`) and \"use a generator expression, not a list comprehension\" so short-circuiting actually pays off. Once those are second nature, you'll find yourself reaching for these on almost every collection check.","pageType":"python"}

any & all

Get Premium