Travis Oliphant wrote: > 2. There is no way for a consumer to tell the protocol-exporting > object it is "finished" with its view of the memory and therefore no way > for the object to be sure that it can reallocate the pointer to the > memory that it owns (the array object reallocating its memory after > sharing it with the buffer object led to the infamous buffer-object > problem).
I'm not sure I'd categorise this problem that way -- it was more the buffer object's fault for assuming that it could hold on to a C pointer to the memory long-term. I'm a bit worried about having a get/release kind of thing in the protocol, because it risks forcing all objects which implement the protocol to provide some kind of refcounting and locking mechanism for their data. Some objects may not be able to do that easily or efficiently, especially if they're wrapping some external library that has no such notion. > All that is needed is to create a Python "memory_view" object that can > contain all the information needed and be returned when the buffer > protocol is called --- when it is garbage-collected, the > "bp_release_view" function is called on the exporting object. That sounds too heavyweight. Getting a memory view through this protocol should be a very lightweight operation -- ideally it shouldn't require allocating any memory at all, and it certainly shouldn't require creating a Python object. -- Greg _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
