On 1/12/07, Timothy Hochberg email@example.com 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.
....)". 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.
 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.