Nick Coghlan <ncogh...@gmail.com> added the comment: I closed 9789 as a duplicate of this. Bringing the details from that issue over here: ==================================== memoryview objects currently offer no way to explicitly release the underlying buffer.
This may cause problems for mutable objects that are locked while PEP 3118 buffer references remain unreleased (e.g. in 3.2, io.BytesIO supports getbuffer() for direct access to the underlying memory, but disallows resizing until the associated memoryview goes away). This isn't too bad in CPython due to explicit refcounting, but may be an issue when using other implementations since the time between release of the last reference and actual garbage collection is indeterminate. For example, the new test_getbuffer in the BytesIOMixin class in the test suite can't rely on "del buf" promptly releasing the underlying PEP 3118 buffer, so it is forced to also invoke a full GC collection cycle in order to be portable to other implementations. So there are two separate questions here: 1. Whether or not to add an explicit "release()" method to memoryview objects (this would be sufficient to address the problem) 2. Whether or not to add direct context management support to memoryview objects (this isn't really necessary, since a short context manager can do the same thing, but may be a nice convenience) Guido was -0 on the idea of supporting the context management protocol, but the rationale presented to him at the time was lacking the key concept of behavioural changes in the object owning the buffer based on whether or not there were any outstanding buffer references. ---------- nosy: +ncoghlan _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9757> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
