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

[Guido van Rossum]

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)