[Python-Dev] Buffer protocol for io.BytesIO?

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

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


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

More information about the Python-Dev mailing list