Carl Banks wrote: > It's easy to see possible use cases for returning a different object. A > hypothetical future incarnation of NumPy might shift the > responsibility of managing buffers from NumPy array object to a hidden > raw buffer object. In this scenario, the NumPy object is the exporter, > but the raw buffer object the provider.
But since the NumPy object has to know about the provider, it can simply pass the release call on to it if appropriate. I don't see how this case necessitates making the release call on a different object. I'm -1 on involving any other objects or returning object references from the buffer interface, unless someone can come up with a use case which actually *requires* this (as opposed to it just being something which might be "nice to have"). The buffer interface should be Blazingly Fast(tm), and messing with PyObject*s is not the way to get that. > > This makes me wonder if releasebuffer should contain an argument which > > states whether or not to release the memory, the shape and strides > > information, the format information, or all of it. > > Here's what I think: the lock should only apply to the buffer itself, > and not to shape and stride data at all. If the requestor wants to keep > its own copies of the data, it would have to malloc its own storage for > it. I expect that this would be very rare. Seems to me the lock should apply to *everything* returned by getbuffer. If the requestor is going to iterate over the data, and there are multiple dimensions, surely it's going to want to refer to the shape and stride info at regular intervals while it's doing that. Requiring it to make its own copy would be a burden. -- Greg _______________________________________________ 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
