Author madison.may
Recipients aisaac, madison.may, mark.dickinson, neil.g, 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 <1379298010.49.0.817803533777.issue18844@psf.upfronthosting.co.za>
In-reply-to
Content
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
History
Date User Action Args
2013-09-16 02:20:10madison.maysetrecipients: + madison.may, tim.peters, rhettinger, mark.dickinson, pitrou, aisaac, westley.martinez, serhiy.storchaka, neil.g
2013-09-16 02:20:10madison.maysetmessageid: <1379298010.49.0.817803533777.issue18844@psf.upfronthosting.co.za>
2013-09-16 02:20:10madison.maylinkissue18844 messages
2013-09-16 02:20:09madison.maycreate