When would you reach for `random.SystemRandom` instead of the `secrets` functions?

## The same class hierarchy, a different source `random.SystemRandom` is a subclass of `random.Random` that replaces the generator underneath. Where `random.Random` produces its bits from MT19937, `SystemRandom` reads them from the operating system's cryptographic random source — the one `os.urandom` exposes. Everything built on top of those bits is inherited unchanged, so a `SystemRandom` instance answers to the full `random` API: `shuffle`, `sample`, `choice`, `randrange`, `randint`, `uniform`, `getrandbits` and the distribution helpers. Two methods behave differently because the source has no state you own: seeding does nothing at all, and there is no state to save or restore, so the save/restore methods refuse. That is the honest consequence of drawing from the OS rather than a defect — a sequence you can reproduce is exactly what a security generator must not offer. `secrets` is a small module built on top of one such instance. `secrets.choice`, `secrets.randbelow` and `secrets.randbits` are the operations the standard library judged that security code needs, plus the three token helpers. It deliberately stops there. ## When the narrow module is not enough Reach for `SystemRandom` when the operation you need is unguessable *and* is not in that short list: * An ordering that must not be predictable — randomised ballot or candidate ordering, shuffling challenge options, randomising the order in which a set of endpoints is probed so an observer cannot anticipate the next one. * Drawing several distinct items without replacement, where `sample` gives you the guarantee of distinctness that repeated `choice` calls do not. * A continuous value from an unpredictable source — an unguessable delay, for instance. For a single unguessable pick, `secrets.choice` is the clearer expression of intent and there is no reason to construct anything. The rule of thumb: `secrets` first, `SystemRandom` when the verb you need is missing from it. ## Why not build it yourself from `os.urandom` The tempting alternative is to take raw bytes and reduce them by hand, and it is where modulo bias enters. Reducing a uniform byte modulo 100 maps 256 equally likely values onto 100 outcomes, and since 256 is not a multiple of 100 the first 56 outcomes each receive three source values while the rest receive two — a measurable skew of roughly 50% toward the low end. The bias grows with the range and with any hand-rolled "make it fit" arithmetic. `secrets.randbelow` and the `SystemRandom` methods avoid this by drawing enough random bits and discarding results that fall outside the range, retrying until one lands inside. That rejection loop is not something to reimplement in application code. Worth stating clearly, because it is a common misconception: the ordinary `random.choice` and `random.sample` are *not* biased either — `random.Random` uses the same rejection technique internally. The difference between `random` and `SystemRandom` is predictability, not fairness. ## The cost, and where it stops being acceptable Every primitive draw from `SystemRandom` goes to the OS source, which is far more expensive than advancing a Mersenne Twister in userspace. For shuffling a few hundred items once per request that cost is invisible. For a simulation drawing millions of values, or a sampling loop in a hot path, it is the wrong tool and plain `random` is right — nothing there needs to be unguessable. ```python import random sysrand = random.SystemRandom() options = ["a", "b", "c", "d"] sysrand.shuffle(options) # unpredictable presentation order picks = sysrand.sample(range(1000), 5) # five distinct values, no repeats print(sorted(options), len(set(picks))) ``` The summary a candidate should be able to give in one breath: `secrets` for tokens and single choices, `SystemRandom` for the rest of the `random` API when predictability matters, and plain `random` everywhere it does not.