Maybe the generalization isn't worthwhile.  I was thinking that maybe a more general version should keep order in types that have order to start with, so I confess I'm not certain what the "correct" interface would be.

But even if it were only for sets, I like the idea of a plain function much better than a method of a set, even if the only arguments it accepted were sets.


On Sat, Jul 6, 2013 at 10:28 PM, Paddy3118 <paddy3118@gmail.com> wrote:


On Sunday, 7 July 2013 03:53:09 UTC+1, David Mertz wrote:
<snip>
  from collections import segment  # tentative name, see various suggestions in thread
  only1, only2, intersection = segment(iter1, iter2)

In behavior, this should do the same thing as the below (just faster):

  def segment(iter1, iter2):
      set1, set2 = map(set, (iter1, iter2))
      return set1 - set2, set2 - set1, set1 & set2
 
Hi David, I really am not sure about generalizing the interface to iterators and then immediately turning them into sets in the implementation. I think the functionality can be naturally explained as an operation on two sets and should be restricted to sets. The caller should have to map other types to sets explicitly. 

If it turns out that the implemented algorithm in C would work just as well with one of the arguments being any finite iterator and the other needing to be a set then we could still stick with requiring two sets or change to a format of:
set_only, common, iter_only = some_set.????(some_iterator)




--
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.