string copying

[Tim Peters]

[Bengt Richter, on consuming vast quantities of memory quickly]
> s = 'x'*2**30 would be a quick gig too. But it made me think
> maybe one could write a sort of memory test (to exercise the
> available python space, anyway).  Does python run out of memory
> gracefully?

Very.  You should get a clean MemoryError exception if you try.

>>> 'x' * 2**30
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError
>>>

There are two things it's not graceful about, due to things beyond its
control:

1. Some OSes "overcommit", i.e. that malloc(n) returns non-NULL
   does *not* mean you can actually write to the returned memory
   addresses.  Python doesn't expect random segfaults upon writing
   to successfully malloc'ed memory.

2. Some OSes go insane if you push them up to, but not over, the
   limit of available memory.  This isn't overcommitment, it's that
   the OS can't actually manage to swap out pieces of itself and
   keep running.  Win9X is extremely prone to this, and system
   crashes are a likely result.  There's nothing Python can do
   about that either.

> I'm afraid to try it (have NT4, 320MB, and too many things running a
> lot).

NT should be fine; Win2K even better.

> Anyway, one could generate binary patterns and chr() the 8-bit
> pieces and join them into say megabyte chunks, and then compare
> sequentially with a the regenerated sequence. ...

A better argument for C coding I've never heard <wink>.