On 15 April 2012 12:40, Stefan Behnel <stefan...@behnel.de> wrote: > mark florisson, 15.04.2012 13:30: >> Finally, what are the semantics for Py_buffer? Will the callee own the >> buffer, or will it borrow it? If they will borrow, then the compiler >> will have to figure out whether it will need to own it (or be slower >> and always own it), and acquire the buffer through buf->obj. At least >> it won't have to validate the buffer, which is the most expensive >> part. >> I think in many cases you want to borrow though, but if you want to >> always own, the caller could do something more efficient if >> releasebuffer is not implemented, like simply incref buf->obj and pass >> in a pointer to a copy of the Py_buffer. I think borrowing is probably >> the easiest and most sane way though. > > I think that's easy. If you request and unpack a buffer yourself, you own > it. If you receive an unpacked buffer from someone else as a call argument, > you borrow it, and you know that your caller (or the caller of your caller, > etc.) owns it and keeps it alive until you return. If you receive it as > return value of a function call, it's less clear, but my intuition tells me > that you'd normally either receive an owned Python object or a borrowed > unpacked buffer. > > In the case at hand, you'd always receive a borrowed buffer from the caller > as argument. > > Stefan > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel
That makes sense, but it means a lot of overhead for memoryview slices, which I think justifies syntax for custom types in general. _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
