Each stage is a generator: a function with yield that produces one item per call. Wrapping lines inside parse_numbers inside positive_only does not run anything; it just builds a chain of iterators. The first next() (or list(...)) walks the chain backwards: the sink asks for one item, the filter asks the parser, the parser asks the source. Because only one item is in flight at a time, the pipeline streams arbitrarily large inputs in O(1) memory. The same shape scales to ETL jobs that read 10 GB of CSV without ever holding more than a row.

Generator stages compose by function application: each stage wraps the previous one. reduce(lambda s, stage: stage(s), stages, source) threads the iterator through every stage left-to-right, which is exactly what a Unix pipe does. map_stage and filter_stage are tiny factories that turn any predicate or transform into a reusable pipeline node. This style is the right tool when stage order is configuration-driven (CLI flags, JSON pipeline definitions) rather than hard-coded function nesting.

The eager version allocates three intermediate lists; for million-row inputs that is three full copies in memory at once. The lazy version replaces every list comprehension with a generator expression (... for ...), so the pipeline is end-to-end streaming. Pair it with itertools.islice (or any consumer that breaks early) and you only pay for the items you actually consume. The mental model is 'pipes, not arrays': data flows, it does not pile up.