[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 -- http://mail.python.org/mailman/listinfo/python-list
