Antoine Pitrou <pit...@free.fr> added the comment: > Antoine is wanting to make release() nondeterministic by having the > underlying buffer only released when all views using it either have > release() called or are no longer referenced.
That's not "nondeterministic" if everyone calls release(). Less so than garbage collection anyway. > I contend that release() needs to mean "release the underlying memory > *right now*" or it is completely pointless. The "I don't want to care > about lifecycle issues" approach is already handled quite adequately > by the ordinary refcounting semantics. Well, if you assume refcounting and no reference cycles, then release() is AFAICT already useless. See issue9757 for the argument we had with Guido ;) My issue is that until now sliced memoryviews are independent objects and are not affected by the releasing of the original memoryview. With this patch, they are, and that's why I'm advocating for a subtler approach (which would really mirror the current slicing semantics, and wouldn't break compatibility ;)). release() is supposed to mean "you can dispose of this memoryview", not "you can dispose of any underlying memory area, even if there's some sharing that I as an user don't know anything about" (*). By making release() affect "related" memoryviews we are exposing an internal implementation detail (the PyManagedBuffer sharing) as part of the API. (*) for something similar, if you close() a file-like object obtained through socket.makefile(), it doesn't close the underlying fd until all other file-like objects are closed too ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10181> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
