[Python-ideas] Extremely weird itertools.permutations

[David Mertz]

On Sat, Oct 12, 2013 at 12:02 AM, Neil Girdhar <mistersheik at 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 at 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 at yahoo.com>wrote:
>>
>>> On Oct 11, 2013, at 19:48, David Mertz <mertz at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131012/5c3479f2/attachment.html>