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

Nick Coghlan ncoghlan at gmail.com
Fri Sep 3 12:44:01 CEST 2010

On Fri, Sep 3, 2010 at 6:54 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

What would be the advantage of having to do two operations? Is it just that you want to make the internal buffer joining step more visible? I was just wondering if it's a good thing to let people, e.g., concatenate a bytes object and a BytesIO by using '+'.

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.

Also, note that the BytesIO object must not be modified while someone reads the buffer. That would be a less obvious side effect if the returned buffer object was different from the BytesIO object itself. 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 is:

with datastream.getbuffer() as buf: ... # any resizing operations on datastream, including read/write raise until the buffer is released

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list