[Cython] CEP1000: Native dispatch through callables
markflorisson88 at gmail.com
Sun Apr 15 13:49:31 CEST 2012
On 15 April 2012 12:40, Stefan Behnel <stefan_ml at 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
>> 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.
> cython-devel mailing list
> cython-devel at python.org
That makes sense, but it means a lot of overhead for memoryview
slices, which I think justifies syntax for custom types in general.
More information about the cython-devel