Where does the value go when a generator function executes `return total`?

## `yield` produces items; `return` produces an ending Inside a generator function the two keywords do genuinely different jobs. `yield` hands an item to whoever is consuming the generator and suspends the frame. `return` ends the generator: the frame unwinds, any `finally` blocks run, and the generator is closed forever. There is no third channel — so what does Python do with the object on a `return`? It attaches it to the exception that already exists for signalling the end. When a generator finishes, it raises `StopIteration`, and that exception has a `value` attribute holding whatever was returned. A bare `return`, or simply running off the end of the body, produces a `value` of `None`. ```python def counted(items): n = 0 for item in items: n += 1 yield item return n # the total, not an item ``` ## Why you have probably never seen it Because every ordinary way of consuming a generator throws it away. A `for` loop, `list()`, `sum()`, a comprehension, `min()` — all of them treat `StopIteration` as a control signal meaning "no more items" and discard the exception object with everything on it. From their point of view a generator that `return`s a total is indistinguishable from one that returns nothing, and no warning is issued. This is a genuine trap: a function written to "return a count at the end" quietly produces nothing observable when someone consumes it with a `for` loop. To see the value you must drive the generator by hand and catch the exception: ```python g = counted("abc") while True: try: print(next(g)) except StopIteration as stop: print("total:", stop.value) break ``` The `as stop` binding is the whole trick: `stop.value` is the returned object. ## What you should do instead, most of the time If a caller needs both a stream and a summary, a return value carried on an exception is a poor interface: it forces every consumer to abandon `for` loops. Better options are to yield the summary as a final, clearly-typed item; to have the generator write the total into an object the caller owns; or to expose a small class with an iteration method plus a `total` attribute, so the two results are ordinary API rather than something smuggled out on a control exception. Reserve the return value for the case where the consumer really is machinery driving the generator step by step. ## The `StopIteration` traps around it **You cannot raise it yourself.** Writing `raise StopIteration(n)` inside a generator body to "return a value" does not work: since PEP 479 (Python 3.7) any `StopIteration` that escapes a generator body is converted into `RuntimeError: generator raised StopIteration`. That change exists because such an exception, escaping accidentally from a nested call, used to end the iteration silently and truncate results. The only supported way to end a generator with a value is `return`. **Empty is not the same as returning.** `StopIteration` with a `value` of `None` is what every plain generator raises when it ends; the attribute exists on every instance, so `stop.value` never raises `AttributeError` — it is simply `None` when there was nothing to return. **`return` still runs `finally`.** The return does not skip cleanup: `finally` blocks in the generator body execute as the frame unwinds, before the `StopIteration` reaches the caller. ## Version history in one line Before Python 3.3, a `return` with a value inside a generator was a `SyntaxError`; 3.3 allowed it and gave `StopIteration` its `value` attribute; 3.7 closed the accidental-`StopIteration` hole; and none of it has changed through 3.14.