On Fri, 3 Sep 2010 20:44:01 +1000
Nick Coghlan
It actually strikes me as a fairly bad thing, so I think you're right to distrust it. Better to follow the precedent set with getvalue() and require an explicit call to getbuffer(). The fact there are two options (immutable copy via getvalue() or mutable accessor via getbuffer()) is all the more reason not to make either conversion implicit.
Thank you for the advice. I think getbuffer() it will be :)
It could not be resized, but it could be modified (same as what happens with bytearrays today). Actually, the buffer itself would be writable, and allow modifying the BytesIO contents.
You may need to be careful with reads and writes while the buffer is exposed (e.g. throwing an exception until the buffer is released again). Perhaps the buffer accessor should be a context manager so it is easy to enforce prompt release?
That's an interesting idea. I was planning to return a memoryview object (in order to hide the intermediate object, and make it really minimal), so perhaps the context protocol should be enabled on memoryviews? (__enter__ would be a no-op, and __exit__ would release the internal buffer and render it invalid, a bit like closing a file) Regards Antoine.