<br><br>On Sunday, 7 July 2013 03:53:09 UTC+1, David Mertz  wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr"><snip></div></blockquote><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr"><div><div class="gmail_quote"><div>  from collections import segment  # tentative name, see various suggestions in thread<br>
</div><div>  only1, only2, intersection = segment(iter1, iter2)<br><br></div><div>In behavior, this should do the same thing as the below (just faster):<br><br></div><div>  def segment(iter1, iter2):<br></div><div>      set1, set2 = map(set, (iter1, iter2))<br>
</div><div>      return set1 - set2, set2 - set1, set1 & set2</div></div></div></div></blockquote><div> </div><div>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. </div><div><br></div><div>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:</div><div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><font face="courier new, monospace">set_only, common, iter_only = some_set.????(some_iterator)</font></div></blockquote></div><div><br></div>