This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author stutzbach
Recipients stutzbach
Date 2010-05-17.18:50:43
SpamBayes Score 2.484911e-06
Marked as misclassified No
Message-id <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-05-17 18:50:46stutzbachsetrecipients: + stutzbach
2010-05-17 18:50:46stutzbachsetmessageid: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>
2010-05-17 18:50:44stutzbachlinkissue8743 messages
2010-05-17 18:50:43stutzbachcreate