On Sat, Oct 12, 2013 at 12:02 AM, Neil Girdhar <mistersheik@gmail.com> wrote:
Why not just use the standard python way to generalize this: "key" rather than the nonstandard "filter_by".

Yes, 'key' is a much better name than what I suggested. 

I'm not quite sure how best to implement this still.  I guess MRAB's recursive approach should work, even though I like the simplicity of my style that takes full advantage of the existing itertools.permutations() (and uses 1/3 as many lines of--I think clearer--code).  His has the advantage, however, that it doesn't require operator.lt() to work... however, without benchmarking, I have a pretty strong feeling that my suggestion will be faster since it avoids all that recursive call overhead.  Maybe I'm wrong about that though.
 
On Sat, Oct 12, 2013 at 1:38 AM, 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.