New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BytesIO and StringIO values unavailable when closed #67288
Comments
IOBase.close() doc says file operations raise ValueError, but it is not obvious to me that reading back the “file” buffer is a file operation. >>> with BytesIO() as b:
... b.write(b"123")
...
3
>>> b.getvalue()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file. Even worse, the memoryview gets corrupted on close(): >>> b = BytesIO(b"123")
>>> m = b.getbuffer()
>>> b.close()
>>> bytes(m)
b'\x98\x02>' I also noticed that in the “io” implementation, writing to the file seems to be completely disallowed, even if it would not seem to change the size: >>> b = BytesIO(b"123")
>>> m = b.getbuffer()
>>> b.write(b"x")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
BufferError: Existing exports of data: object cannot be re-sized |
getvalue() doesn't work after close() for purpose. close() frees memory used by BytesIO. >>> import io, sys
>>> bio = io.BytesIO()
>>> sys.getsizeof(bio)
52
>>> bio.write(b'x'*1000)
1000
>>> sys.getsizeof(bio)
1053
>>> bio.close()
>>> sys.getsizeof(bio)
52 Changing the behavior will cause regression. The behavior of memoryview looks as a bug. |
The BytesIO object should probably reject closing when a buffer is exported.
An enhancement is probably possible there. |
Here is a patch which rejects close() when a buffer is exported. |
Updated patch, to also document the BytesIO buffer is no longer available when closed. The StringIO documentation actually already says this, but I rarely use StringIO. :) |
Why not just copy the StringIO documentation? |
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. |
Yes, it would be good to make the documentation of BytesIO and StringIO 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 :) |
LGTM. |
New changeset e62d54128bd3 by Serhiy Storchaka in branch '3.4': |
New changeset b9d4c013b09a by Serhiy Storchaka in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: