set and frozenset unit tests?

[Raymond Hettinger]

[Jacob Page]
> there are two minor things I
> don't see documented that caught me by surprise:
>
> * Since the <=, <, >, and >= operators raise an exception if the
> right-hand operand is not a set or frozenset,  it seemed reasonable to
> me to assume that == and != should, too.  However, the test suite for
> sets expect the comparisons to be allowed; == between a set and non-set
> return False, != returns True.  Seems inconsistent with the rest of the
> operators, but then again, the odd use of > and < for purposes other
> than ordering also seems strange.

It is consistent with the rest of Python.  It turns out to be somewhat
handy to be able to run an equality test with objects of differing
types:

   if x != None: ...   # doesn't blow-up is x is a string or number

   if 'cat' in [1, 3.1, 'hat']: ...  # doesn't blow-up during eq tests

OTOH, the subset/superset tests pretty much require a set to be on both
sides.  Welcome to the strange and exciting world of rich comparisons.



> * Apparently, if fs is a frozenset instance, fs.copy() returns a
> reference to fs instead of a copy of fs, and frozenset(fs) does the
> same.  The unit tests also ensure that subclasses of frozenset don't do
> this.  It makes sense that it's done that way to save on storage space,
> but it's not documented that this happens.

It is not documented because it is not a guaranteed part of the API.
Most immutables are like this.  Whether equivalent strings and numbers
share the same object id is an implementation detail.


Raymond