> Even worse, the memoryview gets corrupted on close():
The BytesIO object should probably reject closing when a buffer is exported.
> writing to the file seems to be completely disallowed, even if it
> would not seem to change the size:
An enhancement is probably possible there.

I can live with the wording of StringIO, but personally prefer my v2 patch. I now understand that calling close() for Bytes and StringIO objects is intended to immediately free the memory buffer holding the file data (like deleting a file in Windows). So I think it would be better to document this as a property of the whole object, rather than a special exception for each of the getbuffer(), getvalue() non-file-API methods.
I’m happy to propose a similar wording for the StringIO class if you want to make them consistent.

Here is an option that moves the documentation for discarding the buffer into the class description for both BytesIO and StringIO; what do you think? I would be happy enough with any of the last three patches, so I don’t want to hold this up forever :)