[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