On Fri, Sep 3, 2010 at 3:56 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Fri, 3 Sep 2010 20:44:01 +1000 > Nick Coghlan <ncogh...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
