[Python-ideas] Extremely weird itertools.permutations

[David Mertz]

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 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/20131011/fbd59718/attachment.html>