Raymond Hettinger <rhettin...@users.sourceforge.net> added the comment:
Thanks David. Looks like we're all in agreement. Turns out, I did a weeks worth of mulling today ;-) Accepting the proposal with the following rationale: 1. There exist some valid use cases where r>n. 2. Returning an empty list is the expected outcome with two of the current pure python versions (the ones that filter results from product() based on their length, uniqueness and sort). 3. It is consist with the notion of 'all subsets of length r ...' 4. It corresponds to the piecewise definitions of the choose function and binomial coefficient. 5. It matches the battle-tested APIs of all of the major mathematics tools we looked at (Mathematica, Magma, GAP, and Sage. 6. The recipe for combinations_with_replacement() is well defined and useful in cases where r>n -- it is desirable that all the variants of this function keep their APIs in-sync. 7. The three other posters here all agree on it :-) Weighing against it: 1. The ValueError version has already been released. 2. There may be use cases where r>n represents an error so that raising a ValueError would be helpful. 3. The length of the comb/perm doesn't correspond to the non-piecewise, factorial based functions that are so ubiquitous (MS Excel, HP32SII, CRC handbook, Handbook of Mathematics, wikipedia's entries for Combination and Permutation, and GAP's nrCombinations() function). ---------- resolution: -> accepted versions: +Python 2.6, Python 2.7, Python 3.0 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4816> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com