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.

Title: set_contains, etc. should check for collections.Set in addition to PySet_Check
Type: behavior Stage: test needed
Components: Interpreter Core Versions: Python 3.2, Python 2.7
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: rhettinger, stutzbach
Priority: normal Keywords:

Created on 2010-05-18 15:21 by stutzbach, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (2)
msg105983 - (view) Author: Daniel Stutzbach (stutzbach) (Python committer) Date: 2010-05-18 15:21
For operations that test membership in a set, Python coerces sets and subclasses of set into a temporary frozenset before testing membership.

For example, this works:

>>> set() in set([frozenset()])

Although the set() is not hashable itself, Python creates a temporary frozenset() out of the set().  It should do the same for user-types derived from collections.Set, so they can inter-operate in the same way.

In setobject.c, the following methods behave in the described manner: set_contains, set_remove, and set_discard.
msg106004 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-05-18 19:50
I don't think the set methods can make assumptions about whether instances of the Set API can be made frozen.  It is okay to restrict this to just instances of "set" where we know its internal structure and know that its elements are hashable (see the collections docs for an example of a non-hashable set).

Also, the collections.Set methods are supposed to be minimal.  They are not intended to mimic every aspect of regular set objects.
Date User Action Args
2022-04-11 14:57:01adminsetgithub: 52998
2010-05-18 19:50:52rhettingersetstatus: open -> closed

nosy: + rhettinger
messages: + msg106004

resolution: wont fix
2010-05-18 15:21:11stutzbachcreate