Re: [Numpy-discussion] [SciPy-user] Need more comments from scientific community on python-dev
> "Travis" == Travis Oliphant <[EMAIL PROTECTED]> writes: Travis> 2) Examples of sharing memory between two objects. PIL is Travis> the classic example and has some merit, but because the Travis> internal memory layout of the PIL is 'pointer-to-pointers' Travis> instead of 'big-chunk-of-memory' it's not a 1-1 match to Travis> NumPy and the array interface only can comunicate Travis> information about the "mode." But, I can see other Travis> examples. PyMedia, PyGame, PyVideo? CVXOPT, PyVoxel. VTK-Python and TVTK use this. Right now these use the buffer protocol to allow users to pass numpy data into a vtkDataArray. It works reasonably well. The VTK data arrays have type information so it is not absolutely essential for an extended buffer protocol here. TVTK uses this underlying functionality in VTK to present a cleaner interface. The idea is to have VTK use the data setup and manipulated by numpy without an expensive copy. The only caveat is that you need to hang on to a reference of the numpy array if not you will end up with a segfault. I just thought this might be a useful data point. FWIW, I am all for ndarrays/extended buffers in Python core. It would encourage a standard way to pass data in and out of wrapped code. cheers, prabhu - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-user] Need more comments from scientific community on python-dev
On 10/31/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > Fernando Perez wrote: > >I actually worry about the same: I really would like to help, but > >after reading the whole discussion, I realized that the low-level > >details being asked and discussed are something I don't really know > >enough to say anything. And I don't want to sound simply saying 'Hey, > >Travis is great, listen to him!' to python-dev, since that (asides > >from looking silly) can be somewhat counter-productive. > > > > > >How does that sound, Travis? Is that something you think might help > >you, esp. since so many of us are feeling woefully underqualified to > >lend a useful hand in the actual discussion on python-dev? > > > > > > That would be great. I think a couple of things would also be useful. OK, my experience so far has been that there's a certain 'activation barrier' with Wikis, but once pages are there, people for some reason feel more comfortable filling in. So even though it's mostly a place holder, I went ahead and made this: http://www.scipy.org/ArrayInterfacePEP Hopefully as the discussion evolves, this page can be filled in with all the necessary info in one place, and it will become in a few days a solid, organized repository of all the key points in this discussion. This will be a LOT easier to refer to in the python-dev battle than randomly scattered bits of emails in the discussion thread. I'll try to spend more time on it over the next few days to fill in, but I'm pretty busy with other things as well, so hopefully others can pitch in as well. Cheers, f ps - one more thing. This guy: http://blog.vrplumber.com/ has been rewriting the OpenGL bindings using ctypes, and I've seen posts from him about numpy (in his blog). He might be able to contribute something... - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-user] Need more comments from scientific community on python-dev
Fernando Perez wrote: >On 10/31/06, Rich Shepard <[EMAIL PROTECTED]> wrote: > > >>On Tue, 31 Oct 2006, Alan Isaac wrote: >> >> >> >>>The easiest access to this discussion for me was >>>http://news.gmane.org/group/gmane.comp.python.devel/ I cannot add to this >>>discussion, but I REALLY hope others will help Travis out here. (A few >>>have.) He is fielding a lot of questions, some of which look to me to be >>>from individuals who are ready to have fairly strong opinions without >>>really understanding the "why" of his proposals. >>> >>> >> All this is sufficiently far from my areas of expertise that I cannot >>contribute anything useful. Otherwise, I'd be happy to lend support. >> >> > >I actually worry about the same: I really would like to help, but >after reading the whole discussion, I realized that the low-level >details being asked and discussed are something I don't really know >enough to say anything. And I don't want to sound simply saying 'Hey, >Travis is great, listen to him!' to python-dev, since that (asides >from looking silly) can be somewhat counter-productive. > > >How does that sound, Travis? Is that something you think might help >you, esp. since so many of us are feeling woefully underqualified to >lend a useful hand in the actual discussion on python-dev? > > That would be great. I think a couple of things would also be useful. 1) Some way to indicate to python-dev that I'm actually speaking for more than just myself. So, while I agree that just supporting my PEP (which probably in reality needs work) without understanding it is counter-productive, a voice that says. "We really do need this kind of functionality" is at least one more voice. 2) Examples of sharing memory between two objects. PIL is the classic example and has some merit, but because the internal memory layout of the PIL is 'pointer-to-pointers' instead of 'big-chunk-of-memory' it's not a 1-1 match to NumPy and the array interface only can comunicate information about the "mode." But, I can see other examples. PyMedia, PyGame, PyVideo? CVXOPT, PyVoxel. All of these seem to define their own objects which are basically just interpretations of chunks of memory. At one time, we might have said "these should all be sub-classes of the ndarray". Now, we are thinking more along the lines of "these should all expose an array interface". The array interface is still more bulky then it needs to be (it has to go through the attribute-lookup process which can be slow). It would be much better if the extended buffer protocol were available as a function-pointer on the type object of the type. If you have an application where you've ever wanted NumPy in the core. See if the extended buffer protocol serves your purposes and if you agree, voice your approval for the PEP. In my mind, the data-format PEP does not need to go through if there really is a better way to pass data-format information through the buffer protocol. But, the extended buffer protocol we *do* need. -Travis >Regards, > >f >___ >SciPy-user mailing list >[EMAIL PROTECTED] >http://projects.scipy.org/mailman/listinfo/scipy-user > > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-user] Need more comments from scientific community on python-dev
> "Travis" == Travis Oliphant <[EMAIL PROTECTED]> writes: Travis> All of these seem to define their own objects which are Travis> basically just interpretations of chunks of memory. At Travis> one time, we might have said "these should all be Travis> sub-classes of the ndarray". Now, we are thinking more What about blitting pixel buffers from mpl or chaco agg into various GUI windows, GTK, Tk, WX, etc This seems like a ready made case for the array interface. I could pipe in with an example like this if it would help. JDH - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-user] Need more comments from scientific community on python-dev
On 10/31/06, John Hunter <[EMAIL PROTECTED]> wrote: > "Travis" == Travis Oliphant <[EMAIL PROTECTED]> writes:Travis> All of these seem to define their own objects which areTravis> basically just interpretations of chunks of memory. At Travis> one time, we might have said "these should all beTravis> sub-classes of the ndarray". Now, we are thinking moreWhat about blitting pixel buffers from mpl or chaco agg into various GUI windows, GTK, Tk, WX, etc This seems like a ready made casefor the array interface. I could pipe in with an example like this ifit would help.I would also like to see the socket object take a more general type than python strings. I suspect there are a lot of such things in python -- interfaces to services and such -- that would benefit from using a more general interface to memory blocks. But I am not a python developer and don't really know how to make that case. Chuck - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion