This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author madison.may
Recipients NeilGirdhar, aisaac, madison.may, mark.dickinson, pitrou, rhettinger, serhiy.storchaka, tim.peters, westley.martinez
Date 2013-09-16.02:20:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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
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
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
Builds on existing code layout
Value returned directly
Only a single new function required
More compact function name

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:10madison.maysetrecipients: + madison.may, tim.peters, rhettinger, mark.dickinson, pitrou, aisaac, westley.martinez, serhiy.storchaka, NeilGirdhar
2013-09-16 02:20:10madison.maysetmessageid: <>
2013-09-16 02:20:10madison.maylinkissue18844 messages
2013-09-16 02:20:09madison.maycreate