Code to reproduce problem:

population = list(range(10))
weights = list(-1 * w for w in range(10))
[random.choices(population, weights) for _ in range(1000)]

will raise IndexError:

    358         bisect = _bisect.bisect
    359         total = cum_weights[-1]
--> 360         return [population[bisect(cum_weights, random() * total)] for i in range(k)]
    361 
    362 ## -------------------- real-valued distributions  -------------------

IndexError: list index out of range

@ariddell: What behaviour did you want to see here?

It wouldn't have occurred to me to even try using `random.choices` with negative weights; forcing the weights to be nonnegative (with strictly positive sum) sounds like a natural restriction.

Upon some reflection, I think raising a ValueError is the right thing to do. Negative weights don't have an obvious interpretation.

I'm content with the current exception.

It's not a bug, but I agree with Allen that it could use a much more clear error message. I think his proposed ValueError makes a lot more sense than just raising an IndexError as currently occurs. This will help people debug their programs who don't even realize they're accidentally using negative weights to begin with.

I think this should be reopened, as the behavior doesn't always raise an error, and, in fact, does something very unexpected:

Python 3.7.2 (default, Jan 13 2019, 12:50:01)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import Counter
>>> from random import choices
>>> Counter(choices("abcdefg", weights=(1,1,-1,1,1,0,1), k=10000))
Counter({'a': 2569, 'b': 2514, 'e': 2487, 'g': 2430})

It's really not clear to me why supplying a negative weight for "c" should have any effect on "d".

issue37624: not adding an extra O(n) step to check for unusual inputs with undefined meaning -- that would just impair the normal use cases for near zero benefit.

messages: + msg323235
versions: + Python 3.7, - Python 3.6