How do you size an itertools.product space before a nightly billing run enumerates it?

### The scenario A nightly subscription-billing reconciliation walks candidate groupings of fee flags with `itertools.product` and stops finishing inside its window. The 4-person team that owns the job first suspects an encoding mismatch, because the fee-code file is read from an upstream export and a `str`/`bytes` confusion had bitten them before. It is a reasonable first guess and it is wrong: the job is not stuck on a decode, it is enumerating a space nobody counted. This failure has a signature. Memory is flat, the process is at 100% of one core, no exception is ever raised, and adding logging shows tuples streaming past steadily. That combination — healthy memory, no error, no end — is what an oversized lazy enumeration looks like, and it is why the diagnosis is arithmetic rather than a profiler. ### Count first, always Every combinatorial iterator in `itertools` has a closed-form output size, and the standard library computes all of them: ```python import math math.prod([3, 4, 2, 5]) # 120 -> product() of lists with these lengths 10 ** 8 # product(range(10), repeat=8) math.comb(52, 5) # 2598960 -> combinations(deck, 5) math.perm(10, 3) # 720 -> permutations(items, 3) math.factorial(12) # 479001600 -> permutations(items) with r omitted ``` The two shapes of growth are worth naming out loud, because they fail differently. `product` with `repeat=k` is **exponential in k**: adding one more flag doubles a boolean space. `permutations` with `r` omitted is **factorial in n**: 12 items is under half a billion, 15 items is 1.3 trillion, and 20 items is beyond any wall clock. A space that was fine last quarter grows because someone added one element to a list, and the enumeration's shape means one element is not a small change. ### Turning a count into an estimate Time the loop body on a small slice of the space, then multiply. If each tuple costs 20 microseconds and the count is 10**8, that is roughly 2,000 seconds of pure body time before any I/O — already outside a nightly window. Doing this multiplication takes a minute and answers the question that profiling the running job cannot, because the profiler tells you where time goes, not how much of the space remains. Make the count a first-class output of the job. A single line logged at startup — the computed number of tuples, the input lengths that produced it, and the repeat count — turns a silent overnight hang into an obvious number a reviewer can react to. Better still, assert against a ceiling and fail fast: a job that refuses to start above a configured limit is far kinder than one that quietly runs until it is killed. ### What to do when the number is too big Laziness will not save you. `itertools.product` yields one tuple at a time and holds only the input tuples plus the current result, so memory is never the constraint — the constraint is that the loop body runs once per tuple. The fixes are structural: * **Shrink the alphabets.** Deduplicate each input list; equal values in a list multiply the count without adding information. Collapse values that are equivalent for the computation. * **Drop dimensions.** A flag that does not change the outcome should not be in the product at all. Enumerating over it multiplies the whole space by its length for nothing. * **Filter before, not after.** A `product` over pre-filtered input lists is exponentially smaller than a `product` over full lists with a filter on the output tuples, because every rejected element is removed from every position it would have occupied. * **Split the enumeration.** If a condition depends on only the first two positions, enumerate those two, test, and only then take the product of the rest for survivors. This is the point where a hand-written nested loop can beat `product`, because it can skip whole subtrees rather than generating them. * **Reconsider whether enumeration is the right model at all.** Many spaces that look combinatorial have a direct or greedy formulation, and the interviewer will be glad you asked the question. ### Getting the pruning boundary right One caution about splitting: an enumeration that is exponential stays exponential after pruning unless the pruning removes a dimension rather than a fraction of the tuples. Cutting 90% of a 10**8 space still leaves 10**7 items. Prune where it removes a factor, not where it removes a slice. ### What good looks like in the answer The strong response has four beats: recognize the symptom (flat memory, one hot core, no exception, no end); reach for the closed-form count instead of a profiler; convert count times per-tuple cost into a wall-clock estimate; and then propose structural fixes plus a startup log or assertion so the same failure is loud next time. Naming `math.prod`, `math.comb` and `math.perm` shows you know the counting is a one-liner, and saying plainly that **laziness bounds memory rather than time** is the sentence that separates a candidate who has operated one of these jobs from one who has only read about iterators.