Message105929
The set() operators (__or__, __and__, __sub__, __xor__, and their in-place counterparts) require that the parameter also be an instance of set().
They're documented that way: "This precludes error-prone constructions like set('abc') & 'cbs' in favor of the more readable set('abc').intersection('cbs')."
However, an unintended consequence of this behavior is that they don't inter-operate with user-created types that derive from collections.Set.
That leads to oddities like this:
MySimpleSet() | set() # This works
set() | MySimpleSet() # Raises TypeError
(MySimpleSet is a minimal class derived from collections.Set for illustrative purposes -- set attached file)
collections.Set's operators accept any iterable.
I'm not 100% certain what the correct behavior should be. Perhaps set's operators should be a bit more liberal and accept any collections.Set instance, while collections.Set's operators should be a bit more conservative. Perhaps not. It's a little subjective.
It seems to me that at minimum set() and collections.Set() should inter-operate and have the same behavior. |
|
Date |
User |
Action |
Args |
2010-05-17 18:50:46 | stutzbach | set | recipients:
+ stutzbach |
2010-05-17 18:50:46 | stutzbach | set | messageid: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za> |
2010-05-17 18:50:44 | stutzbach | link | issue8743 messages |
2010-05-17 18:50:43 | stutzbach | create | |
|