Use Weighted Random Sampling in Python

Select a timestamp to watch that moment on YouTube.

1. 00:00

   Imagine a simulation with two outcomes. A has weight zero and B has weight one. Can A appear? If the program is using the weights correctly, the answer is no. This gives us a sharper test than asking whether a short sample merely looks plausible. A different example with weights one and three would give both outcomes a chance, but even a thousand draws would not be guaranteed to follow an exact one-to-three count. Today we will build a wrapper that accepts a population, a weight vector, and a random generator. We will first run a plausible-looking broken version, then inspect the API call that actually determines the distribution.

2. 00:41

   Uniform choice gives each item an equal chance. A game, simulation, or classroom experiment may instead assign different relative weights. Python's random.choices accepts a population and weights; a zero weight makes that outcome impossible when another weight is positive. We inject a random.Random instance so tests can reproduce a sequence without modifying global random state. Weights are relative values, not percentages: one and three give a one-to- three ratio, and ten and thirty describe the same distribution. This tool is for simulation, not for passwords or security tokens.

3. 01:21

   The broken run holds a weights list next to the items but calls choice rather than choices. Watch the terminal sequence: with the selected seed, a zero-weight A may appear, which contradicts the stated rule. The unused variable can fool a quick code review because its presence makes the function look as though it considered weights. A seed does not fix that. Seeding means we can replay the same incorrect result and discuss it precisely. The question is which argument reaches the random method. Pause on the line with choice and observe that it receives only items. That method performs a uniform draw; it cannot infer our separate weight list.

4. 02:03

   The broken run calls rng.choice even though a weight list is present. The code looks random and may pass a casual test, but it ignores the policy altogether. With an outcome weighted zero, any selection of that outcome reveals the bug decisively. Predict whether the uniform sampler can still pick A when A has weight zero in a separate list. A seeded generator makes the diagnostic repeatable, but a seed does not make an incorrect algorithm weighted. It only makes the same incorrect sequence easier to inspect. In the diagnosis we make two draws for several seeds: one through choice and one through choices with weights.

5. 02:44

   The contrast does not depend on a vague impression of frequency. Weighted draws never produce A because its weight is zero and B's is positive. Uniform draws can produce A. Notice that choices returns a list because it supports requesting k outcomes at once. For our single-outcome helper, we pass k equal to one and select the first element of that list. We also need to decide what happens for empty items, mismatched lengths, negative numbers, NaN, infinity, and an all-zero total. Those inputs should fail at our boundary before we ask the library to sample. Before calling choices, validate that the population is nonempty, that the two lists

6. 03:26

   have equal length, that every weight is finite and nonnegative, and that their sum is positive. Negative or NaN weights do not describe a useful distribution. Then call rng.choices(population, weights=weights, k=1)[0]. It returns a one-element list because choices is designed to draw any number of outcomes. The index selects the single requested result. This small wrapper gives a readable API and a place to enforce the input contract. The fixed wrapper checks the shape and each weight before drawing. The code uses math.isfinite so NaN and infinity cannot enter an undefined or

7. 04:07

   misleading probability calculation. All weights must be nonnegative, and at least one must be positive. We pass an injected Random instance instead of calling a global function, which keeps tests independent and makes a simulation reproducible when we deliberately reuse a seed. Then the call to choices uses the weight vector. The final index extracts one item, matching our function name and task contract. On screen, five different seeds still all choose B when A's weight is zero. Trace the validation order before the final library call. The nonempty and equal-length checks prevent ambiguous pairing of item and

8. 04:47

   weight. The finite, nonnegative, positive-total checks make zero meaningful without allowing all outcomes to be impossible. The method receives both lists and k equal to one; its return type is a list, so index zero produces a single selected item. Nothing here asserts a particular answer for a positive-weight random draw. Our exact unit tests use the zero-weight invariant and the input errors instead. This distinction between deterministic invariants and probabilistic estimates is the main testing lesson behind the implementation.

9. 05:27

   The last run checks twenty seeds and observes the set of possible results. That set contains only B. It also passes an all-zero vector and confirms that we reject it with ValueError. These are boundary tests, not proof that a one-to-three example will always have exactly one A for every three B results. If you want to study a distribution, run many trials and state sampling uncertainty. If you need a password, token, or security choice, do not reuse this simulation helper; use a cryptographic source designed for that purpose. In the article exercise, try changing the relative weights while preserving their ratio and explain what stays the same.

10. 06:10

    The final run checks a zero-weight boundary across multiple draws and rejects an all-zero weight list. It does not claim that five draws prove a three-to-one ratio; randomness needs many observations for a statistical estimate and even then individual outcomes vary. A zero-weight outcome is a deterministic invariant, which makes it a stronger unit test. If the application needs cryptographic unpredictability, use the secrets module and design that requirement separately. For ordinary reproducible simulations, pass a Random object instead of relying on hidden global state.