[Numpy-discussion] Need more comments from scientific community on python-dev

[Travis Oliphant]

Fernando Perez wrote:

>On 10/31/06, Rich Shepard <rshepard at appl-ecosys.com> 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
>SciPy-user at scipy.org
>http://projects.scipy.org/mailman/listinfo/scipy-user
>  
>