How do itertools.chain and itertools.chain.from_iterable differ when flattening a list of lists?

### What chain actually is `itertools.chain` is lazy concatenation over iterables. `chain(a, b, c)` returns an iterator that yields every item of `a`, then every item of `b`, then every item of `c`, and stops. It allocates no intermediate container: the concatenated stream exists only as a cursor into whichever inner iterable is currently being drained. That makes it the iterator equivalent of `a + b + c` for lists, except that nothing is copied and the inputs need not be sequences at all — files, generators, sets, `dict` views and range objects all chain happily. ### The two spellings Real data rarely arrives as separate variables. It arrives as one container *of* containers: a list of pages, a generator of chunks, an iterator of records each of which is itself a list of fields. Two spellings flatten that shape: ```python itertools.chain(*rows) itertools.chain.from_iterable(rows) ``` They yield identical items, and for a short in-memory list of lists either is fine. The difference is **when the outer container is consumed**. `*rows` is argument unpacking, performed by the interpreter before `chain` ever runs. Python walks `rows` to the end, collects every element into a tuple, and passes them as positional arguments. Three consequences follow. If `rows` is a generator that reads a huge file chunk by chunk, that generator is driven to completion before a single item comes out the other side. If `rows` is unbounded, the unpacking never returns — the call hangs, and it is not `chain` that is hanging. And if `rows` has a million entries you have just materialised a million-element argument tuple, which is exactly the memory you were trying to avoid. `chain.from_iterable(rows)` — a class method on `chain` — takes the outer iterable as its one argument and pulls from it lazily, requesting the next inner iterable only once the current one is exhausted. Peak extra memory is one inner chunk plus whatever the outer iterable holds open, and the outer may legitimately be infinite because nothing forces it. ### Exactly one level of flattening Neither form recurses. `chain.from_iterable([[1, [2]], [3]])` yields `1`, `[2]`, `3` — the inner list survives untouched as an item. Arbitrarily nested structures need an explicit recursive generator; chain is not a deep-flatten tool and claiming it is one is a common interview slip. The corollary that bites in production is `str`. A string is an iterable of one-character strings, so chaining a list of names yields characters, not names, and no error is raised anywhere — the bug shows up far downstream as suspiciously many one-character values. If the inner elements might be strings, wrap or filter them deliberately. ### Why not sum(rows, []) or a += loop `sum(rows, [])` builds a brand-new list at every step and copies everything accumulated so far into it, which is quadratic in the total number of items; on a large batch it is the difference between milliseconds and minutes. `sum` also refuses `str` outright with a `TypeError` that steers you to `str.join`. A nested comprehension, `[x for row in rows for x in row]`, is linear and perfectly idiomatic — the honest comparison is *comprehension when you want a list, chain when you want a stream*. Reach for `chain.from_iterable` when the flattened result is going to be consumed once, immediately, and possibly not to the end. ### Practical properties worth stating The result is an iterator, so it is one-shot: no `len()`, no indexing, and a second `for` over it yields nothing. Chaining zero iterables (`chain()`), or iterables that are all empty, simply yields nothing rather than raising. Inner iterables are not touched until the stream reaches them, which means a file opened lazily inside a generator of rows is only opened when its turn comes — useful, and also a resource-lifetime trap if the caller abandons the chain half way and expects everything to have been closed. ### Choosing between them Use `chain(a, b)` when you genuinely have a handful of named iterables. Use `chain.from_iterable(rows)` whenever the iterables come from a container or a stream — it is shorter than `chain(*rows)`, it never has to build an argument tuple, and it keeps the outer producer lazy. Treating `chain(*rows)` as the default is the mistake: it works right up until the outer iterable is large, slow or endless, and then it fails in a way that points at the wrong line.