Madison May added the comment: 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 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18844> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
