set and frozenset unit tests?

[Jacob Page]

I have released interval-0.2.1 at
http://members.cox.net/apoco/interval/. IntervalSet and
FrozenIntervalSet objects are now (as far as I can tell) functionality
equivalent to set and frozenset objects, except they can contain
intervals as well as discrete values.

Though I have my own unit tests for verifying this claim, I'd like to
run my code through actual set and frozenset unit tests. Does any such
code exist? Is it in pure Python? If so, where can it be obtained?

Oh, and again, I'd really appreciate additional feedback on the module,
especially related to design, if you've got any. My goal for this
project is to make the classes built-in-data-type quality.

 

[Reinhold Birkenfeld]

I have released interval-0.2.1 at
http://members.cox.net/apoco/interval/. IntervalSet and
FrozenIntervalSet objects are now (as far as I can tell) functionality
equivalent to set and frozenset objects, except they can contain
intervals as well as discrete values.

Though I have my own unit tests for verifying this claim, I'd like to
run my code through actual set and frozenset unit tests. Does any such
code exist? Is it in pure Python? If so, where can it be obtained?

Oh, and again, I'd really appreciate additional feedback on the module,
especially related to design, if you've got any. My goal for this
project is to make the classes built-in-data-type quality.

Look at /usr/lib/python2.x/test/ (on unix platforms).

Reinhold

 

[Jacob Page]

Look at /usr/lib/python2.x/test/ (on unix platforms).

Thanks for pointing that to me. For some reason, the Debian package for
python 2.4 doesn't include those tests, but I acquired them from an
alternative source.

Oye, there's quite a number of set and frozenset features that aren't
well-documented that I now need to implement. What a fun chore!

 

[Steven Bethard]

Oye, there's quite a number of set and frozenset features that aren't
well-documented that I now need to implement. What a fun chore!

It would be a great help if you could submit appropriate documentation
patches for the areas you don't think are well-documented:

http://sourceforge.net/tracker/?group_id=5470&atid=305470

STeVe

 

[Jacob Page]

It would be a great help if you could submit appropriate documentation
patches for the areas you don't think are well-documented:

Hmm, after closer scrutiny, I'm not sure if the documentation really
does need modification. The largest incompatibility between IntervalSet
and set was that my code wasn't enforcing hashability, and that property
of sets actually IS documented. However, 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.

* 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.

Both issues seem to be pretty minor unless you're making functionally
equivalent classes. I'm sure neither one will confuse someone into
using them improperly, so I think it's fine to leave the docs alone.

By the way, IntervalSet and FrozenIntervalSet, when used in place of set
and frozenset, now pass most of the tests. One notable difference
between them is that whereas sets can contain any hashable object,
IntervalSet elements must be both hashable and orderable (implement
__cmp__). Thus, commands like IntervalSet([FrozenIntervalSet(...)])
fail, unlike set([frozenset(...)]).

I've also changed the methods with mixedCase capitalization to
lower_case_with_underscores, as recommended by PEP 8.

Version 0.2.2 of the module can now be downloaded from
http://members.cox.net/apoco/interval/. I'm about to freeze the
interfaces and transition the module to beta, so if you have any
interest in the project or design change ideas, please send feedback soon.

 

[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