[SciPy-user] [Numpy-discussion] Need more comments from scientific community on python-dev
oliphant at ee.byu.edu
Tue Oct 31 11:04:48 CST 2006
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.
>SciPy-user mailing list
>SciPy-user at scipy.org
More information about the SciPy-user