On 1/12/07, Timothy Hochberg <[EMAIL PROTECTED]> 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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
