> Can you suppress the MemoryError if deletion succeeds? That would be ok IMO.

In case (1) and (3) (see below), the MemoryError might be suppressed, but I prefer to keep the exception to warn the user that something bad happened and its program will slowly leak memory.

Reminder that I found the error using failmalloc which is stupid tool: it injects random MemoryError errors. In practice, realloc() should never fail if the buffer is shrinked (becomes smaller). So I don't think that you should worry too much on the exact behaviour of this case :-)

Only the case (3) (bytearray grows) may appear in practice, and this case is handleded correctly (do nothing if realloc() failed, leave the bytearray object unchanged).


> Yes, but if a MemoryError occurred during slice assignment b[3:6] = b'ab', the bytearray will be not consistent. For consistency we should copy replacement bytes.

Correct, fixed in new patch.


New patch copying bytes if the memory allocation failed but we cannot restore removed bytes (case 2). I also added a long comment explaining the issue.

Behaviour with the patch 3:

Case 1: growth<0, lo == 0

>>> b=bytearray(b'asciiUNICODE'); b[:5]=b'#'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError
>>> b
bytearray(b'asciiUNICODE')

=> b leaved unchanged (ok)


Case 2: growth<0, lo != 0

>>> b=bytearray(b'asciiUNICODE'); b[1:5]=b'#'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError
>>> b
bytearray(b'a#UNICODE')

=> function succeed, but exception raised (and memory block not resized)


Case 3: growth>0

>>> b=bytearray(b'asciiUNICODE'); b[5:5]=b'###'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError
>>> b
bytearray(b'asciiUNICODE')

=> b leaved unchanged (ok)