Message197862
Serhiy, from a technical standpoint, your latest patch looks like a solid solution. From an module design standpoint we still have a few options to think through, though. What if random.weighted_choice_generator was moved to random.choice_generator and refactored to take an array of weights as an optional argument? Likewise, random.weighted_choice could still be implemented with an optional arg to random.choice. Here's the pros and cons of each implementation as I see them.
Implementation: weighted_choice_generator + weighted_choice
Pros:
Distinct functions help indicate that weighted_choice should be used in a different manner than choice -- [weighted_choice(x) for _ in range(n)] isn't efficient.
Can take Mapping or Sequence as argument.
Has a single parameter
Cons:
Key, not value, is returned
Requires two new functions
Dissimilar to random.choice
Long function name (weighted_choice_generator)
Implementation: choice_generator + optional arg to choice
Pros:
Builds on existing code layout
Value returned directly
Only a single new function required
More compact function name
Cons:
Difficult to support Mappings
Two args required for choice_generator and random.choice
Users may use [choice(x, weights) for _ in range(n)] expecting efficient results |
|
Date |
User |
Action |
Args |
2013-09-16 02:20:10 | madison.may | set | recipients:
+ madison.may, tim.peters, rhettinger, mark.dickinson, pitrou, aisaac, westley.martinez, serhiy.storchaka, NeilGirdhar |
2013-09-16 02:20:10 | madison.may | set | messageid: <1379298010.49.0.817803533777.issue18844@psf.upfronthosting.co.za> |
2013-09-16 02:20:10 | madison.may | link | issue18844 messages |
2013-09-16 02:20:09 | madison.may | create | |
|