[New-bugs-announce] [issue8743] set() operators don't work with collections.Set instances

[Daniel Stutzbach]

New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

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.

----------
components: Interpreter Core
files: set-vs-set.py
messages: 105929
nosy: stutzbach
priority: normal
severity: normal
stage: unit test needed
status: open
title: set() operators don't work with collections.Set instances
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17383/set-vs-set.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8743>
_______________________________________