Btw. My implementation of nonredundant_permutations *IS* guaranteed to work by the docs for Python 3.4.  Actually for Python 2.7+.  That is, it's not just an implementation accident (as I thought before I checked), but a promised API of itertools.permutations that:

  Permutations are emitted in lexicographic sort order. So, if the
  input iterable is sorted, the permutation tuples will be produced in
  sorted order.

As long as that holds, my function will indeed behave correctly (but of course, with the limitation that it blows up if different items in the argument iterable cannot be compared using operator.lt().

On Fri, Oct 11, 2013 at 10:38 PM, David Mertz <mertz@gnosis.cx> wrote:
Hi Andrew,

I've sort of said as much in my last reply to Nick.  But maybe I can clarify further.  I can imagine *someone* wanting a filtering of permutations by either identify or equality.  Maybe, in fact, by other comparisons also for generality.

This might suggest an API like the following:

  equal_perms = distinct_permutations(items, r, filter_by=operator.eq)
  ident_perms = distinct_permutations(items, r, filter_by=operator.is_)

Or even perhaps, in some use-case that isn't clear to me, e.g.

  start_same_perms = distinct_permutations(items, r, filter_by=lambda a,b: a[0]==b[0])

Or perhaps more plausibly, some predicate that, e.g. tests if two returned tuples are the same under case normalization of the strings within them.

I guess the argument then would be what the default value of 'filter_by' might be... but that seems less important to me if there were an option to pass a predicate as you liked.



On Fri, Oct 11, 2013 at 7:57 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Oct 11, 2013, at 19:48, David Mertz <mertz@gnosis.cx> wrote:

> My feeling, however, is that if one were to trim down the results from a permutations-related function, it is more interesting to me to only eliminate IDENTICAL items, not to eliminate merely EQUAL ones.

I agree with the rest of your message, but I still think you're wrong here. Anyone who is surprised by distinct_permutations((3.0, 3)) treating the two values the same would be equally surprised by {3.0, 3} having only one member. Or by groupby((3.0, 'a'), (3, 'b')) only having one group. And so on.

In Python, sets, dict keys, groups, etc. work by ==. That was a choice that could have been made differently, but Python made that choice long ago, and has applied it completely consistently, and it would be very strange to choose differently in this case.



--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.



--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.