> My proposal is that for someone coming from using NumPy from Python,
> they only need declare their object (say x) as being a numpy array,
> and then all access to x.shape is suddenly faster rather than having
> to remember a new way to access shape, ndim, etc.
I've been ranting about this before, so I'll be brief [edit: I failed],
but I have strong feelings (and a strong investment in the summer too)
in this.
The problem is that typical usecases want to either use the Python API
(though *invisibly* optimized), or the C API. I don't see a need for the
in-between crossbreed.
Explicitly, I'd love for the following to fail, hard:
cdef int* s = arr.shape
cdef object s = raw_arr.dimensions
("cdef object s = arr.shape" should work though, but I consider that
GSoC-stuff, not something you can fake at this stage.)
We might just have to agree that we disagree on this one. Though
remember: Explicit is better than implicit.
Renaming the fields at least keep the APIs relatively seperate. Even if
the Python API is provided, there are still usecases for the native API.
For instance, how can one implement the ndarray inlines if there's no
raw access? If there's no way to access the raw C API but one relies on
"magic" then they will create infinite loops.
Perhaps the following can be a compromise?:
cdef extern ...
ctypedef struct ndarray_extension_struct "PyArrayObject":
int nd
Py_intptr_t *dimensions
cdef class numpy.ndarray [object PyArrayObject]:
property shape:
cdef inline final object __get__(self):
cdef ndarray_extension_struct* raw = \
<ndarray_extension_struct*>self
return make_tuple_from(raw.dimensions, raw.nd)
# And if you want auto-conversion to int-array,
# add a type-overload like this:
cdef inline final Py_intptr_t* __get__(self):
cdef ndarray_extension_struct* raw = \
<ndarray_extension_struct*>self
return raw.dimensions
So if you really want access to the raw struct, there's a predefined way.
Lisandro's proposal is a lot easier on the fingers though ("return
make_tuple_from(self.cshape, self.cndim)").
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
