[Numpy-discussion] Latest Array-Interface PEP
Torgil Svensson
torgil.svensson at gmail.com
Fri Jan 12 14:18:38 CST 2007
On 1/12/07, Timothy Hochberg <tim.hochberg at ieee.org> wrote:
> Things that act like arrays, but have different storage methods. This
> details of this still seem pretty vague, but to the extent that I can figure
> them out, it doesn't seem useful or necessary to tie this into the rest of
> the array interface PEP.
Looks like an array, act like an array, smells like an array = is an array
> For example,
> "array_interface->get_block_from_slice()" has been
> mentioned. Why that instead of
> "PyObject_AsExtendedBuffer(PyObject_GetItem(index),
What is an "Extended buffer" ? Connecting that to array information
doesn't feel intuitive.
> ....)"[2]. I'll stop here, till I see some more details of what people have
> in mind, but at this point, I think that alternative memory models are a
> different problem that should be addressed separately.
I agree
> [1] Remind me again why we can't simply use ctypes for this?
1. ctypes is designed for "c types", not "array layout"
2. managing/creating complex formats in ctypes deviates from the
clean, intuitive and simple (considerably compared to dtypes) => ugly
code
3. Can ctypes handle anonymous lambda function pointers?
> the core. I'm sure it's less efficient, but you shouldn't need to parse the
> data structure information very often.
I believe that'll be more common than you think; for example
dynamically creating/combining/slicing recarrays with various data.
//Torgil
More information about the Numpy-discussion
mailing list