Antoine Pitrou, 03.09.2010 12:56: > On Fri, 3 Sep 2010 20:44:01 +1000 > Nick Coghlan wrote: >> >> It actually strikes me as a fairly bad thing, so I think you're right >> to distrust it. +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) I can't see a reason not to support that. Sounds a lot simpler than requiring to set the memory view reference to None in order to trigger a cleanup at an undefined point in time. Stefan
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