[Python-ideas] exclusively1, common, exclusively2 = set1 - set2, set1 & set2, set2 - set1

Mon Jul 8 09:47:50 CEST 2013

Yeah, needs to be on sets/dictionary types otherwise question of equality versus identity comes into play. Not to mention the behavior of shared gets pretty ambiguous: if there is one of them in one and two in the other, do two of them go in common, one in common and xor2. I think it makes sense as a standard method of the set type, if it makes sense at all; and also that "vennsubs" might be a good name. Could accept any itterable composed of hashable (that's what makes a viable key, righ?) items. 
On Jul 8, 2013, at 12:22 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Sun, Jul 07, 2013 at 02:37:56PM -0700, David Mertz wrote:
>> On Jul 7, 2013 2:09 PM, "Eric V. Smith" <eric at trueblade.com> wrote:
>>>>>> On 7/7/2013 1:45 AM, David Mertz wrote:
>>>> 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.
>>>>>> If it were added, I think a classmember on set would be reasonable.
>>>> I agree.
>> A class member? Do you mean a class *method*?
>> I think it would be freaky and weird if I did this:
>> some_set.venn_split(second_set, another_set)
>> (for lack of a better name) and the value of some_set was ignored. Class 
> methods are okay for things like alternate constructors, but I don't 
> think they are appropriate here.
>>>> -- 
> Steven
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas