groupby(iterable) yields a (key, group_iter) pair every time the key changes between consecutive items. Without a key= argument it groups by element identity, which makes one-line run-length encoding trivial. The 'a' run at the end shows up as a separate group because the second 'a' run is not adjacent to the first. RLE is the canonical example, but the same shape pops up in 'longest streak of green builds', 'plateaus in a stock chart', and any other 'consecutive equal' question.

When you want a true 'group by user' (not just consecutive runs), sort by the same key first and groupby will give you exactly one group per distinct key. operator.itemgetter('user') is a tiny callable that pulls a dict field, faster than lambda x: x['user'] and clearer at the call site. Without the sort, the example would yield two 'ana' groups and two 'ben' groups. For most workloads collections.defaultdict(list) is simpler than 'sort then groupby', but groupby shines when you stream data or already have it sorted.

Each group is a thin iterator into the same underlying stream as the outer groupby, not an independent list. Consuming it twice gives an empty result the second time. Worse, advancing the outer loop (or materializing it with list(groupby(...))) silently invalidates every previous group object. The safe pattern is: convert each group to a list immediately inside the loop, or aggregate it (sum, count, max) before moving on. This is one of the top three Python interview gotchas.