What does an `as` pattern such as `case [x, y] as pair` bind in a `match`?

## The problem it solves A pattern that destructures throws the container away. `case [x, y]:` gives you the two elements, but nothing that names the list itself. A literal or or-pattern is worse: `case "GET" | "HEAD":` tells you the subject was one of two strings but leaves you no name holding which one. The **AS pattern** fixes both. ## Syntax and semantics The form is `<pattern> as <name>`. The left-hand pattern is tried first. If it matches, `<name>` is bound to **the value that pattern matched**, in addition to any captures inside the pattern. If the left-hand pattern fails, nothing is bound by the AS pattern and the case is rejected as usual. The subtlety worth getting right in an interview is *which* value gets bound, and it depends on position: * **Top level of a `case`** — the value matched is the subject of the `match`, so `case [x, y] as pair:` binds `pair` to the whole sequence. * **A sub-position** — the value matched is only that sub-value. In `case {"point": [_, _] as pair}:` the name `pair` holds the inner two-element list; the mapping itself is not bound by anything. ```python def inspect(payload): match payload: case {"point": [_, _] as pair}: return pair case _: return None inspect({"point": [1, 2], "id": 7}) # [1, 2] ``` ## The idiomatic uses **Keeping the whole thing after destructuring.** When the body needs both the parts and the original — to re-emit it, log it, or pass it on — `as` saves a second lookup and keeps the case self-describing. **Naming the result of an or-pattern.** This is the pairing you will most often see: ```python match verb: case ("GET" | "HEAD") as method: return f"read: {method}" ``` Without `as`, the body knows the subject was one of the alternatives but has no name for which one. And because `as` binds the *same* name whichever alternative matched, it satisfies the or-pattern rule that every alternative bind the same names — with the bar inside the group and the `as` outside it, there is only one binding to reconcile. **Naming a value a pattern only tested.** A pattern that merely constrains the subject without destructuring it can be given a name in the same breath, keeping the case readable without a separate assignment in the body. ## Interaction with guards The `as` binding happens as part of matching, which completes before the case's guard is evaluated. So the guard may read it: `case ("GET" | "HEAD") as method if method in allowed:` works. As with every capture, the binding survives a failed guard — the name is still set even though the case was rejected — so restrict your use of it to the body of the case that bound it. ## Outside the alternatives or inside them Both placements compile, and they are worth being able to compare. `case ("a" | "b") as ch:` wraps the whole group and binds once, whichever alternative won. `case ("a" as ch) | ("b" as ch):` puts an `as` inside each alternative and is also legal — both alternatives bind exactly `{ch}`, so the rule that alternatives bind the same names is satisfied. The outer form is shorter, obviously correct by construction, and the one to reach for; the inner form only earns its keep when the alternatives need to bind *different* sub-values under the one shared name. ## Rules and errors The target must be a plain, valid name. The wildcard is not a name, so it cannot be a target: ```python case [1, 2] as _: # SyntaxError: cannot use '_' as a target ``` An AS pattern is **irrefutable exactly when its left-hand pattern is**. `case _ as everything:` matches anything, and just like a bare `case _:` it makes any following clause unreachable — the compiler reports `wildcard makes remaining patterns unreachable`. `case [x] as pair:` is refutable, because the sequence pattern can fail, so cases after it are fine. Note also that a bare capture name and an AS pattern are different constructs that happen to look related. `case pair:` is a capture pattern that matches everything and binds `pair`; `case [x, y] as pair:` still *tests* the subject and only then binds. Confusing the two is the mistake that produces an accidental catch-all. ## Where it sits AS patterns arrived with the rest of structural pattern matching in Python 3.10 (PEP 634) and have not changed through 3.14. They are a comfort feature rather than a gate — most interview `match` questions never reach them — but reaching for one naturally in a live-coding exercise reads as fluency with the statement.