Where does a name bound by Python's `:=` in an `if` condition live afterwards?

### Same binding rules as `=` The whole answer starts here: `:=` is not a new kind of name binding, it is the expression form of the one Python already had. Where the name lands is decided by the usual rules of the enclosing scope: * in a function body, the name is a **local** of that function — and, as with any assignment, the compiler decides that statically for the entire function, not from the moment the line runs; * at module level, it is a **global**; * in a class body, it is a class-body local, which becomes a class attribute; * a `global` or `nonlocal` declaration redirects it exactly as it would redirect a normal assignment. Nothing about `:=` creates a scope. That is worth saying explicitly because the operator *looks* like something exotic, and candidates often guess it must be confined to the expression it appears in. ### Python has no block scope, and that is the point `if`, `while`, `for`, `with` and `try` do not introduce scopes in Python. A name assigned inside one is visible after it, subject only to whether the assignment actually ran. So: ```python def describe(values): if (total := sum(values)) > 10: label = "large" else: label = "small" return f"{label}:{total}" # total is still here ``` `total` survives the `if` and the function's tail can use it. If the walrus somehow confined the name to the condition, the operator would be nearly useless — the entire capture-and-test idiom depends on the body being able to read what the condition bound. ### Binding happens on evaluation, not on branch entry A common misconception is that the name is only bound when the branch is taken. It is bound when the sub-expression is *evaluated*, which happens while the condition is being computed: ```python if (n := 3) > 10: ... print(n) # 3, even though the branch was skipped ``` This matters when you want the value regardless — you can test one thing and still use the captured value in the `else`. ### The genuine trap: short-circuiting `and` and `or` do not evaluate their right operand when the left one already decides the result. Put a walrus on the right and its binding becomes conditional: ```python def resize(job, enabled): if enabled and (width := job.get("width")): return width return width # UnboundLocalError when enabled is falsy ``` When `enabled` is falsy the right operand never runs, `width` is never bound, and because the compiler already marked `width` as a function local, reading it raises `UnboundLocalError` rather than falling back to a global. In an image-thumbnail worker with a 45-second cold start, this is the kind of defect that survives a smoke test — the happy path binds the name every time, and only the disabled-feature path, hit later under real traffic, blows up. The same applies to `or`, and to any conditional expression whose branch contains the binding. The defences are ordinary ones: initialise the name before the condition, restructure so the binding is unconditional, or do not put a walrus behind a short-circuiting operator at all. The last is the rule most teams adopt, because it removes the reasoning entirely. ### Leaked names as a readability cost Because the name outlives the block, a walrus in a long function quietly extends that function's set of live locals. One or two, used immediately, are fine and are the reason the operator exists. A dozen scattered through conditions produce a function where a reader cannot tell where a name came from without scanning every condition — the binding is buried mid-line rather than sitting at the start of a statement where the eye expects it. That is the honest limit of the feature. `:=` improves readability when it removes a duplicated computation, a priming read, or a one-line temporary that exists only to be tested next. It degrades readability when the bound name travels far from its binding, when several appear in one condition, or when the surrounding expression is already long. Reviewers should read a walrus and ask two questions: what exactly gets bound, and is the name used close enough that the binding is still visible? Everything here is unchanged since PEP 572 landed in Python 3.8 and holds on 3.14. The one context where the scoping story is genuinely different is a comprehension, which has its own rules and is a topic in its own right.