Hi Joe: On Sat, 24 Apr 2010, Joe Blaylock wrote: > And if so, is there any reason I can't rewrite this as x.intersect(y) > to make it explicit? I'm not wild about the use of bitwise operators > with operands which aren't (explicitly defined to be) bits.
One may naturally use x.intersection(y) and friends, but `x & y' is a perfectly legitimate equivalent with Python built-in sets, so there should be no need to change that? Besides, set's intersection() accepts any iterable, while intbitset's intersection() accepts only intbitsets, so it may actually be of interest to use `&' and not intersection() in the current API state, in order to highlight the behavioural similarities with sets. Compare: a = set([1, 3]) a & set([2,3,4]) a & [2,3,4] # error a.intersection(set([2,3,4])) a.intersection([2,3,4]) # okay x = intbitset([1,3]) x & intbitset([2,3,4]) x & [2,3,4] # error (the same behaviour as sets) x.intersection(intbitset([2,3,4])) x.intersection([2,3,4]) # error (different behaviour than sets) We may perhaps want to change intbitset's intersection() behaviour in order to align it fully to that of the sets. But until then, `&' seems better to use, due to these subtle behavioural similarities and differences with sets. Best regards -- Tibor Simko
