-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support comparisons with other types. #18
Comments
Mmh but: > set.__eq__(set([1,2,3]), [1,2,3])
... NotImplemented
> set.__eq__(set([1,2,3]), set([1,2,3]))
... True
> set([1,2,3]) == [1,2,3]
... False
> set([1,2,3]) == set([1,2,3])
... True So what is actually the reference implementation to follow? |
> set.__eq__(set([1,2,3]), [1,2,3])
... NotImplemented I cannot reproduce this. Returns > set.__eq__(set([1,2,3]), set([1,2,3]))
... True This is basically > set([1,2,3]) == [1,2,3]
... False This is comparing two different types, which is always > set([1,2,3]) == set([1,2,3])
... True |
That's weird. Are you actually typing the above?
|
# python2.7
Python 2.7.7 (default, Sep 24 2014, 12:01:43)
[GCC 4.7.3] on linux
>>> set.__eq__(set([1,2,3]), [1,2,3])
False
>>>
# python3.4
Python 3.4.1 (default, Nov 1 2014, 12:34:56)
[GCC 4.7.3] on linux
>>> set.__eq__(set([1,2,3]), [1,2,3])
NotImplemented
>>> set([1,2,3]) == [1,2,3]
False After some hunting in the bugtracker, it seems that the internal behavior of where comparisons occur was changed somewhere in 2.7.8. (For example, for ABCs: http://bugs.python.org/issue8743) The interpreter uses some "other" fallback to provide an answer when the rich comparison operators are used. I am not sure about how this works, but ebb8865dcf54 (and PyAnySet_Check) may lead to the answer. FWIW, >>> object.__ne__([1,2,3], set([1,2,3]))
True Edit: After an IRL chat it seems that one should simply return NotImplemented and let the interpreter resolve that to a |
* Comparing an intbitset with anything that is not an intbitset should behave as a set would. E.g. intbitset([1,2,3]) == set([1,2,3]) is False. (closes inveniosoftware-contrib#18) Signed-off-by: Samuele Kaplun <samuele.kaplun@cern.ch> Reported-by: Dimitrios Semitsoglou-Tsiapos <dsemitso@cern.ch>
Perhaps a different issue, but could we also support operations with other kinds of sets? intbitset([1,2]) | {1,2,3} intbitset([1,2]).union({1,2,3}) Edit: In [11]: frozenset([1,2]) | {1,2}
Out[11]: frozenset({1, 2})
In [12]: {1,2} | frozenset([1,2])
Out[12]: {1, 2} |
* Comparing an intbitset with anything that is not an intbitset should behave as a set would. E.g. intbitset([1,2,3]) == set([1,2,3]) is False. (closes inveniosoftware-contrib#18) Signed-off-by: Samuele Kaplun <samuele.kaplun@cern.ch> Reported-by: Dimitrios Semitsoglou-Tsiapos <dsemitso@cern.ch>
* Comparing an intbitset with anything that is not an intbitset should behave as a set would. E.g. intbitset([1,2,3]) == set([1,2,3]) is False. Referenced-by: #18 Contributed-by: Samuele Kaplun <samuele.kaplun@cern.ch> Reported-by: Dimitrios Semitsoglou-Tsiapos <dsemitso@cern.ch> Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Using any comparison operator on an intbiset with anything that is not an intbitset results in the following:
It should instead return
False
as aset
would.The text was updated successfully, but these errors were encountered: