
A Python `bool` is one of two values: `True` or `False`. Comparisons (`==`, `<`, `in`) and logical operators (`and`, `or`, `not`) produce booleans. Beyond the two bool literals, many other values behave as true or false in a boolean context - this is called "truthiness."

<ExamplePair>
<ExampleProse>

`bool(x)` converts any value to its boolean equivalent. The falsy values are: `0`, `0.0`, `""`, `b""`, `[]`, `()`, `{}`, `set()`, and `None`. Every other value is truthy. You can rely on this in `if` conditions without calling `bool()` explicitly.

</ExampleProse>
<ExampleCode>

```python
# All falsy
bool(0)     # False
bool("")    # False
bool([])    # False
bool({})    # False
bool(None)  # False

# All truthy
bool(1)         # True
bool("hello")   # True
bool([0])       # True  - a list with one item, even if the item is 0
bool(0.001)     # True
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`and` and `or` do not necessarily return `True` or `False` - they return one of their operands. `or` returns the first truthy operand (or the last operand if all are falsy). `and` returns the first falsy operand (or the last operand if all are truthy). This short-circuit behaviour is useful for defaults, but it also creates a common footgun.

</ExampleProse>
<ExampleCode>

```python
# or returns the first truthy value
0 or "fallback"         # 'fallback'
"primary" or "fallback" # 'primary'
[] or [1, 2]            # [1, 2]

# and returns the first falsy value
1 and 2                 # 2   (all truthy, returns last)
0 and "unreachable"     # 0   (0 is falsy, short-circuits)

# Footgun: silently uses the fallback when 0 or "" is a valid value
count = 0
display = count or "no items"   # 'no items' -- wrong when count is a valid 0
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`is` checks identity - whether two names refer to the same object in memory. `==` checks value equality. For `None`, `is` is the canonical idiom and is faster. For `True` and `False`, use truthiness (`if x:`) rather than `is True` or `is False` - they are fragile if the value is a truthy non-bool.

</ExampleProse>
<ExampleCode>

```python
x = None
x is None       # True  - canonical None check
x == None       # True  - works, but non-idiomatic

# is True / is False are footguns
result = 1      # truthy, but not the bool True
result == True  # True
result is True  # False  - 1 and True are different objects

# Prefer plain truthiness checks
if result:       # idiomatic - "do I have a value?"
    pass
if result is not None:  # idiomatic - "was something provided?"
    pass
```

</ExampleCode>
</ExamplePair>

<InProduction>
`if my_list:` treats empty containers as false - convenient for "do I have items?", but catastrophic when `0`, `""`, or `[]` is a legitimate value (a counter starting at zero, an empty form field, a response body that is intentionally empty). Use `if x is not None:` when the distinction between "absent" and "falsy but present" matters. `and`/`or` return operands not booleans, so `default = config_value or "fallback"` silently uses the fallback for `0`, `""`, and `[]`.
</InProduction>


Python bool - True and False, truthy and falsy values, short-circuit operators, and when to use is vs ==.

Booleans and Truthiness


Python's branching uses `if`, `elif`, and `else`. For a quick inline choice there is the conditional expression (`a if condition else b`). Since Python 3.10 there is also structural pattern matching with `match` and `case`, which matches on the shape and contents of a value rather than just equality.

<ExamplePair>
<ExampleProse>

An `if`/`elif`/`else` chain evaluates each condition in order and runs the first branch that is true. `elif` is short for "else if" - you can have as many as you need. The `else` branch runs when no earlier condition matched.

</ExampleProse>
<ExampleCode>

```python
def classify_status(code: int) -> str:
    if code < 200:
        return "informational"
    elif code < 300:
        return "success"
    elif code < 400:
        return "redirect"
    elif code < 500:
        return "client error"
    else:
        return "server error"

classify_status(200)  # 'success'
classify_status(404)  # 'client error'
classify_status(503)  # 'server error'
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

The conditional expression (`value_if_true if condition else value_if_false`) fits a two-way choice on one line. It is useful for short, readable choices. Nesting conditional expressions inside one another is a code-review smell - use a regular `if`/`else` block instead.

</ExampleProse>
<ExampleCode>

```python
n = 7
label = "even" if n % 2 == 0 else "odd"
label  # 'odd'

# Readable: one level deep
status = "active" if user.is_logged_in else "guest"

# Avoid: nested ternaries are hard to read at a glance
# result = "a" if x else ("b" if y else "c")  -- use if/elif/else
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`match`/`case` (Python 3.10+) is structural pattern matching - it inspects the shape and contents of a value, not just its equality. A `case` clause can destructure a dict, pull out fields by name, and bind them as local variables in one step. One important detail: `case x:` with a bare name always binds (it never compares), so use a dotted name like `case Color.RED:` to compare against a constant.

</ExampleProse>
<ExampleCode>

```python
def handle(event: dict) -> str:
    match event:
        case {"type": "click", "x": x, "y": y}:
            return f"click at ({x}, {y})"
        case {"type": "keypress", "key": key}:
            return f"key: {key}"
        case {"type": str(t)}:
            return f"unknown event type: {t}"
        case _:
            return "malformed event"

handle({"type": "click", "x": 10, "y": 20})   # 'click at (10, 20)'
handle({"type": "keypress", "key": "Enter"})   # 'key: Enter'
```

</ExampleCode>
</ExamplePair>

<InProduction>
`match` is structural pattern matching, not a C-style switch - it matches shape, not just equality. Reach for it on tagged dicts, parsed JSON, AST nodes, and message envelopes where you want to destructure and bind fields in one step; for plain equality dispatch a chain of `elif` is clearer. `case x:` with a bare name binds rather than compares - use a dotted name (`case Color.RED:`) or a guard (`case x if x == sentinel:`) when you need literal comparison.
</InProduction>


Python branching with if/elif/else, conditional expressions, and structural pattern matching with match/case (3.10+).

Conditionals


A Python `str` is an immutable sequence of Unicode code points - not bytes. The separate `bytes` type holds raw binary data. Converting between them requires an explicit `.encode()` call (str to bytes) or `.decode()` call (bytes to str), and you must name the encoding each time.

<ExamplePair>
<ExampleProse>

f-strings (formatted string literals) embed expressions directly inside `{}`. They support Python's full format-spec syntax for alignment, padding, and number formatting - the same spec used by `format()` and `str.format()`.

</ExampleProse>
<ExampleCode>

```python
name = "Ada"
f"Hello, {name}!"         # 'Hello, Ada!'

value = 3.14159
f"{value:.2f}"            # '3.14'  (2 decimal places)

n = 42
f"{n:>10}"                # '        42'  (right-aligned in 10 chars)
f"{n:0>10}"               # '0000000042'  (zero-padded)
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`str` and `bytes` are separate types and Python never converts between them automatically. `.encode(encoding)` produces `bytes`; `.decode(encoding)` produces `str`. If the bytes do not match the encoding you name, Python raises `UnicodeDecodeError` - pass `errors="replace"` to substitute replacement characters instead of crashing.

</ExampleProse>
<ExampleCode>

```python
s = "héllo"
b = s.encode("utf-8")       # b'h\xc3\xa9llo'  (5 chars -> 6 bytes)

b.decode("utf-8")            # 'héllo'

# Wrong codec raises UnicodeDecodeError
b.decode("ascii")            # UnicodeDecodeError: invalid start byte

# Safety valve: replace undecodable bytes with the replacement character
b.decode("ascii", errors="replace")   # 'h��llo'
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`len(s)` counts Unicode code points, not characters as humans perceive them (graphemes). A single visible character can be multiple code points when combining marks are used - for example, the letter `a` followed by a combining accent. Naive slicing can split a grapheme in the middle. Normalising with `unicodedata.normalize("NFC", s)` folds as many combining sequences as possible into single composed code points before slicing or comparing.

</ExampleProse>
<ExampleCode>

```python
import unicodedata

# 'a' + combining acute accent = two code points, one visible character
composed = "á"          # á  (precomposed, 1 code point)
decomposed = "á"       # a + combining acute, 2 code points

len(composed)                # 1
len(decomposed)              # 2

# Normalize to NFC before comparing or slicing user input
unicodedata.normalize("NFC", decomposed) == composed   # True
```

</ExampleCode>
</ExamplePair>

<InProduction>
f-strings evaluate arbitrary expressions inside `{...}` - never format untrusted input as if it were a template string; use `str.format_map` with a restricted mapping, or better, keep user input as data rather than embedding it in format strings. `len(s)` counts code points, not graphemes - naive slicing of user input with emoji or combining marks produces mojibake; normalise with `unicodedata.normalize("NFC", s)` or reach for the `regex` package before truncating display strings.
</InProduction>


Python str is an immutable sequence of Unicode code points, not bytes. Encoding, f-strings, and grapheme-aware slicing.