When do you reach for io.StringIO instead of ''.join() to build a large Python string?

## Two builders, one cost class Both idioms exist because `str` is immutable and repeated concatenation copies. Both are linear in the final length, so performance rarely decides between them; the decision is about the *shape* of the producing code and about what you need to be able to take back. **`"".join(parts)`** is the sequence-shaped builder. You append fragments to a list — amortized constant time per append — and join at the end. Join makes two passes: one to total the lengths and pick the widest character width required, so it can allocate the result buffer exactly once, and one to copy every fragment in. **`io.StringIO`** is the write-shaped builder. It is an in-memory text stream with the same `write()` API as an open file, so it buffers internally and hands you the whole text on `getvalue()`. Nothing touches the filesystem — the "IO" is the interface, not the destination. ## When the write-shaped one wins The first reason is composition. If a payload is assembled by half a dozen helpers, a list forces every helper either to return fragments the caller must splice, or to accept and mutate a list. Passing a single writer is cleaner, and the same helper works unchanged against a real file object or a socket wrapper because they share the `write()` interface. That is the polymorphism you buy. The second reason is rollback, and it is the one that earns the choice in production. Consider a metrics scraper that assembles a text exposition payload, one block per collector. A collector can fail halfway through emitting its block, and a half-written block is worse than a missing one — downstream parsers choke on it. With a stream you take a mark before the block and rewind on failure: ```python import io buf = io.StringIO() for collector in collectors: mark = buf.tell() try: collector.emit(buf) except CollectorError: buf.seek(mark) buf.truncate() # drop the partial block payload = buf.getvalue() ``` `truncate()` with no argument cuts the stream at the current position, so the failed block leaves no trace. One caveat worth knowing: seeking *past* the end of an `io.StringIO` and then writing pads the gap with null characters, so only ever seek back to a mark you actually recorded. The list version of the same pattern is equally valid and needs no import: record `mark = len(parts)` before the block and `del parts[mark:]` on failure. Say both in an interview — the interesting content is that you need a rollback point at all, and that a plain `s += ...` accumulator gives you none, because rebinding a name leaves you no offsets to return to and holding the previous string just to restore it keeps a second reference alive. ## Memory, which is the real trap Neither builder streams. At the moment `join` allocates, the list of fragments and the finished string are both live, so peak memory is roughly the payload twice over, plus per-object overhead for every fragment — and a Python object header per fragment is not nothing when there are hundreds of thousands of them. `io.StringIO` has the same property: the internal buffer and the string returned by `getvalue()` coexist. Under a 27-minute soak run of a scraper this is what shows up as a sawtooth in resident memory rather than as latency, and it is why `getvalue()` on a very large buffer is a poor place to be surprised. The fix, when the payload is genuinely large, is not a better builder — it is not to build it at all. If the consumer is a socket or a file, write through to it: the helpers already take a writer, so passing the real destination instead of the in-memory one is a one-line change, memory becomes constant, and the first bytes leave earlier. The cost is that you lose the rollback ability, because you cannot un-send what you have already flushed. That tradeoff — buffer for atomicity, stream for memory — is the senior answer. ## Bytes rather than text When the fragments are octets, the text builders are the wrong tool. Accumulate into a `bytearray`, which is genuinely mutable, so `+=` and `extend()` really do append rather than copy, and convert once with `bytes(buf)` at the end. `io.BytesIO` is the stream-shaped equivalent, with the same `tell`/`seek`/`truncate` rollback trick available. ## Answering crisply Join when you have a sequence; a stream when you have writers or need to rewind; write through to the destination when the payload is too big to hold; and a `bytearray` when it is bytes. What an interviewer listens for is not a preference but the reasoning: composition, rollback, and peak memory.