Control Flow

Python evaluates an `if/elif/else` chain top-down and runs **only the first branch** whose condition is `True`. Subsequent `elif` tests are skipped even if they would also evaluate true. This top-down short-circuit is why ordering matters: write the most specific test first, the most general (`else`) last.

The expression after `if` does not need parentheses, but the colon at the end is mandatory. Indentation is syntactic, not cosmetic. Mixing tabs and spaces raises `TabError`. PEP 8 mandates 4 spaces per level; every modern editor (VS Code, PyCharm, Jupyter) inserts 4 spaces when you press Tab inside a `.py` file.

For exactly two cases, Python provides a **conditional expression** (ternary): `value if test else other`. This compresses three lines into one and is the idiomatic style for assigning a value based on a single check. Reserve `if/elif/else` blocks for branches that contain multiple statements or side effects.

A `for` loop in Python walks an **iterable**, not an integer range. Strings, lists, tuples, dicts, sets, files, and generators are all iterable. Writing `for c in "hello":` prints each character; writing `for line in open("data.txt"):` reads one line per iteration without loading the file into memory. This makes `for` the workhorse loop for 80% of homework code.

The `range(start, stop, step)` function generates integers without materializing a list. `range(10)` produces `0, 1, ..., 9`. `range(1, 11)` produces `1` through `10`. `range(10, 0, -1)` counts down from `10` to `1`. The stop value is **exclusive** in every form, which is the source of the off-by-one errors that plague every CS101 midterm.

Three iteration helpers from the stdlib appear in every well-written solution: `enumerate(items)` yields `(index, value)` pairs, `zip(a, b)` walks two iterables in lockstep, and `reversed(items)` walks in reverse. Combining them, `for i, (x, y) in enumerate(zip(xs, ys)):` is the standard form for "track index while walking two parallel lists".

A `while` loop runs as long as its condition stays `True`. The condition is **rechecked at the top** of each iteration; if it starts `False`, the loop body never executes. Use `while` when the iteration count is not known in advance: reading user input until a sentinel, polling a queue, retrying a network call.

The two failure modes of `while` are the same in every language. An **infinite loop** runs when the condition variable is not updated inside the body. An **off-by-one** runs one iteration too many or too few when the condition uses `<` instead of `<=`. Guard against both by writing the exit condition first, then the update step.

For reading input until the user enters a sentinel, the canonical Python pattern is `while True: ... if exit_condition: break`. This is preferred over `while exit_condition:` because the exit check happens after the read, which mirrors how stdin actually behaves. The `break` keyword exits the nearest enclosing loop; `continue` jumps to the next iteration.

The `break` statement exits the **innermost** enclosing loop immediately. The `continue` statement skips the rest of the current iteration and re-tests the loop condition. Both apply to `for` and `while` identically. Use them sparingly; deep `if/elif/break` chains usually mean the loop body wants to be a separate function.

Python provides a feature most languages lack: the **`else` clause on loops**. A `for/else` or `while/else` runs the `else` block when the loop exits **normally**, meaning without hitting a `break`. This is the canonical pattern for "search and report not-found": loop through candidates, `break` on a match, fall through to `else` for the no-match case. Cleaner than a separate `found` flag.

Nested loops add the **labeled break** problem: `break` exits only the inner loop. Two options: refactor the inner block into a function and `return`, or set a sentinel flag checked by the outer loop. The function approach is preferred. Functions also make the autograder error trace easier to read.

Python 3.10 introduced `match/case` for structural pattern matching. Unlike a C-style `switch`, match patterns destructure values: extract fields from tuples, dicts, and class instances in the same step as branching. This replaces long `if isinstance(x, T):` chains in parser and tree-walking code.

A `match` expression compares the subject against each `case` pattern in order. The first matching pattern runs; remaining cases are skipped. Patterns are not values; they are templates. The literal pattern `case 0:` matches the integer `0`. The capture pattern `case x:` matches any value and binds it to `x`. The class pattern `case Point(x=0, y=y):` matches a `Point` instance with `x` equal to `0` and binds the `y` attribute.

The `_` wildcard pattern is the catch-all. Place it last to handle the "everything else" case. Without a wildcard, an unmatched subject falls through silently, which is rarely what you want. CS50P does not yet test `match` in problem sets, but DATA 100 and CS229 final projects use it for token classification and AST walks.