Re: [Python-Dev] An updated extended buffer PEP

2007-03-28 Thread Greg Ewing
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

Re: [Python-Dev] An updated extended buffer PEP

2007-03-28 Thread Greg Ewing
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

Re: [Python-Dev] An updated extended buffer PEP

2007-03-28 Thread Carl Banks
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

Re: [Python-Dev] An updated extended buffer PEP

2007-03-28 Thread Carl Banks
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 >>>

Re: [Python-Dev] An updated extended buffer PEP

2007-03-27 Thread Travis Oliphant
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

Re: [Python-Dev] An updated extended buffer PEP

2007-03-27 Thread Greg Ewing
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

Re: [Python-Dev] An updated extended buffer PEP

2007-03-27 Thread Greg Ewing
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

Re: [Python-Dev] An updated extended buffer PEP

2007-03-27 Thread Travis Oliphant
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

Re: [Python-Dev] An updated extended buffer PEP

2007-03-27 Thread Travis E. Oliphant
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

Re: [Python-Dev] An updated extended buffer PEP

2007-03-27 Thread Travis E. Oliphant
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; >

Re: [Python-Dev] An updated extended buffer PEP

2007-03-27 Thread Carl Banks
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'

Re: [Python-Dev] An updated extended buffer PEP

2007-03-26 Thread Greg Ewing
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

Re: [Python-Dev] An updated extended buffer PEP

2007-03-26 Thread Greg Ewing
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

Re: [Python-Dev] An updated extended buffer PEP

2007-03-26 Thread Travis Oliphant
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 > > > > __

[Python-Dev] An updated extended buffer PEP

2007-03-26 Thread Travis Oliphant
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