[Python-Dev] Buffer protocol for io.BytesIO? (original) (raw)

Guido van Rossum guido at python.org
Fri Sep 3 18:32:22 CEST 2010

On Fri, Sep 3, 2010 at 3:56 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

On Fri, 3 Sep 2010 20:44:01 +1000 Nick Coghlan <ncoghlan at gmail.com> wrote:

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 :)

+1

> 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)

So far I'm -0 on this. I'm not sure if it solves a real problem, and I think that if we were to add a way to define the scope of a buffer operation using a with-statement, it should work for all objects that support the buffer protocol (which IIUC means more than just memoryview). I'd be more enthusiastic about a separate context manager to wrap any such object.

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list