Logged In: YES 
user_id=34209

Well, I got unbored long enough to finish most (byte)string
tests, and do some tuple testing too. But, boy, do those
need a lot of memory. The 16Gb box I was testing on took 4
days to finish the tuple tests -- and I had to quickly add a
spare disk as swap, as the 20Gb I had allocated was just not
enough :)

Here's a completely reworked testfile. It adds a few things:

 - Support for 'bigmem tests' in test_support, and a
command-line option to regrtest. If bigmem tests aren't
explicitly enabled in regrtest, the tests are still run,
just with very small sizes (in order to test the tests
themselves.) Enabling the test is done by passing an upper
memory limit, and the framework tries to get tests to stay
inside that limit.

 - Instead of 'size' as a class attribute, each test is
decorated with a minimum size and expected memory use (in
bytes per size). The decorator calculates the allowable size
from the memory use and the limit, and skips the test if
it's going to take too much memory even with the minimum
size. In verbose mode, it warns that it skipped a file.

As I said, the tuple tests take quite a lot of memory, and
you probably don't want to the tests to start swapping (swap
is quite, quite slow.) However, not many of these tests can
be run with less than 8Gb of memory, and that'll just cover
the string tests and a few of the simpler tuple tests.

On the plus side, while the string tests found several bugs
in the Py_ssize_tification, the tuple tests found none. Or
perhaps that's a downside? I'm not sure. Anyway,
everything's here to build tests for more datatypes: dicts,
lists, sets and unicode strings come to mind (where testing
unicode strings is the most likely to discover bugs, and
should only take 2 to 4 times as much memory as the string
tests), but there's also array, buffer and probably more in
modules that can do with similar tests.