Carl Banks wrote:
> Now object B takes a view of A. If we don't have this field, then B
> will have to hold a reference to A, like this:
>
> B -> A -> R
>
> A would be responsible for keeping track of views,
A isn't keeping track of views, it's keeping track of the
single object R, which it h
Carl Banks wrote:
> /* don't define releasebuffer or lockbuffer */
> /* only objects that manage buffers themselves would define these */
That's an advantage, but it's a pretty small one -- the
releasebuffer implementation would be very simple in
this case.
I'm bothered that the releaser field m
Carl Banks wrote:
> Here's a concrete example of where it would be useful: consider a
> ByteBufferSlice object. Basically, the object represents a
> shared-memory slice of a 1-D array of bytes (for example, Python 3000
> bytes object, or an mmap object).
>
> Now, if the ByteBufferSlice objec
Travis Oliphant wrote:
> Carl Banks wrote:
>> Travis E. Oliphant wrote:
>>> I think we are getting closer. What do you think about Greg's idea
>>> of basically making the provider the bufferinfo structure and having
>>> the exporter handle copying memory over for shape and strides if it
>>>
Carl Banks wrote:
> Travis E. Oliphant wrote:
>> I think we are getting closer. What do you think about Greg's idea
>> of basically making the provider the bufferinfo structure and having
>> the exporter handle copying memory over for shape and strides if it
>> wants to be able to change those
Travis Oliphant wrote:
> Perhaps, though we can stick with an
> object-less buffer interface but have this "view object" as an expanded
> buffer object.
I like this idea.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
Travis E. Oliphant wrote:
> Greg Ewing wrote:
>> struct bufferinfo {
>> ...
>> };
>>
>> int (*getbuffer)(PyObject *obj, struct bufferinfo *info);
>> int (*releasebuffer)(PyObject *obj, struct bufferinfo *info);
> This is not much different from my original "view" object. Stick a
> P
Lisandro Dalcin wrote:
> On 3/26/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>> Here is my updated PEP which incorporates several parts of the
>> discussions we have been having.
>
> Travis, it looks really good, below my comments
I hope you don't mind me replying to python-dev.
>
> 1- Is it ha
Carl Banks wrote:
> Travis Oliphant wrote:
>> Travis Oliphant wrote:
>>> Hi Carl and Greg,
>>>
>>> Here is my updated PEP which incorporates several parts of the
>>> discussions we have been having.
>> And here is the actual link:
>>
>> http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/doc
Greg Ewing wrote:
> Here's another idea, to allow multiple views of the same
> buffer with different shape/stride info to coexist, but
> without extra provider objects or refcount weirdness.
> Also it avoids using calls with a brazillion arguments.
>
>struct bufferinfo {
> void **buf;
>
Travis Oliphant wrote:
> Travis Oliphant wrote:
>> Hi Carl and Greg,
>>
>> Here is my updated PEP which incorporates several parts of the
>> discussions we have been having.
>
> And here is the actual link:
>
> http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/doc/pep_buffer.txt
What'
Here's another idea, to allow multiple views of the same
buffer with different shape/stride info to coexist, but
without extra provider objects or refcount weirdness.
Also it avoids using calls with a brazillion arguments.
struct bufferinfo {
void **buf;
Py_ssize_t *len;
int *wri
Travis Oliphant wrote:
> > Here is my updated PEP which incorporates several parts of the
> > discussions we have been having.
It looks pretty good.
However, I'm still having trouble seeing what use it is returning
a different object from getbuffer. There seems to be no rationale
set out for th
Travis Oliphant wrote:
> Hi Carl and Greg,
>
> Here is my updated PEP which incorporates several parts of the
> discussions we have been having.
>
And here is the actual link:
http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/doc/pep_buffer.txt
> -Travis
>
>
>
> __
Hi Carl and Greg,
Here is my updated PEP which incorporates several parts of the
discussions we have been having.
-Travis
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://ma
15 matches
Mail list logo