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 :) > > 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4