I thought it would be nice if mmaps could generally look a little more
like sequences. Specifically, being able to resize+write using
square-bracket notation as with lists:

>>> x = [1,2,3,4,5]
>>> x
[1, 2, 3, 4, 5]
>>> x[2:2] = [6,7,8,9]
>>> x
[1, 2, 6, 7, 8, 9, 3, 4, 5]
>>>

If that could be done when x is an mmap.mmap, it'd be great.
alternatively, if mmap had an insert or an extend method that work like
with lists, the same behavior could be achieved without relying on mmap
specific method-names.

@Brian this will go nowhere without a patch covering code, tests and documentation, are you interested in providing one?

I see a few issues with this:

1. Changing the default behavior is a compatibility issue. I've written code that depends on exceptions being raised if slice assignment sizes don't match.
2. The performance cost is high; changing from rewriting in place to shrinking or expanding slice assignment requires (in different orders for shrink/expand) truncating the file to the correct length, memcpy-ing data proportionate to the data after the end of the slice (not proportionate to the slice size) and probably remapping the file (which causes problems if someone has a buffer attached to the existing mapping). At least with non-file backed sequences, when we do work like this it's all in memory and typically smallish; with a file, most of it has to be read from and written to disk, and I'd assume the data being worked with is "largish" (if it's reliably small, the advantages of mmap-ing are small).
3. Behavior in cases where the whole file isn't mapped is hard to intuit or define reasonably. If I map the first 1024 bytes of a 2 GB file, and I add 20 bytes in the middle of the block, what happens? Does data from the unmapped portions get moved? Overwritten? What about removing 20 bytes from the middle of the block? Do we write 0s, or copy down the data that appears after? And remember, for all but the "shrink and write 0s" option, we're moving or modifying data the user explicitly didn't mmap.

I am closing this because in the 13 years since it was opened there was only one (negative) response and I don't think this will be picked up now.

If you still want to pursue this idea, I would suggest raising it on python-ideas to get more feedback, and then possibly reopening this or creating a new issue.