New submission from Daniel Stutzbach <dan...@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 <rep...@bugs.python.org>
<http://bugs.python.org/issue8743>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
