On 12 February 2012 15:18, Dag Sverre Seljebotn <d.s.seljeb...@astro.uio.no> wrote: > On 02/11/2012 10:27 PM, mark florisson wrote: >> On 11 February 2012 20:31, Charles R Harris<charlesr.har...@gmail.com> >> wrote: >>> Hi Dag, >>> >>> This probably needs to be on the cython mailing list at some point, but I >>> thought I'd start the discussion here. Numpy is going to begin deprecating >>> direct access to ndarray/dtype internals, ala arr->data etc. There are >>> currently macros/functions for many of these operations in the numpy >>> development branch and I expect more to go in over the coming year. Also, >>> some of the macros have been renamed. I don't know the best way for Cython >>> to support this, but the current version (0.15 here) generates code that >>> will fail if the deprecated things are excluded. Ideally, numpy.pxd would >>> have numpy version dependent parts but I don't know if that is possible. In >>> any case, I'd like your thoughts on the best way to coordinate this >>> migration with Cython. >>> >>> Chuck >>> >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion@scipy.org >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>> >> >> This was discussed not too long ago on the cython-devel mailing list: >> http://mail.python.org/pipermail/cython-devel/2012-January/001848.html >> >> I personally think it'd be nice to not break existing Cython code, by >> e.g. writing nogil cdef properties (something which doesn't currently >> exist). That way the properties could use the non-deprecated way to >> actually access the data from numpy. (In any case the deprecated numpy >> functionality should go through a deprecation process before being >> removed). > > The only attribute that really concerns me is shape. > > For the rest, I think it's OK to require using the C API. E.g., the data > is a Python attribute returning something else, and exposing the C field > was a mistake in the first place. > > If we remove the shape field, it would still work (through the Python > getattr), but this might in some locations give a speed regresssion > (and, in many places, not).
My concern with that is that it doesn't work in nogil mode. But maybe not that many people are using it in nogil mode and can readily change the code to use the macro or memoryviews if wanted. > If we do anything about this, then I really think we should emulate the > Python API in full, so that one could finally do "print a.shape", > "len(a.shape)"; even if "a.shape[0]" is fast. > > This requires something else that just cdef properties though -- perhaps > a typed tuple type in addition. It could return a view on the shape :p. >> Alternatively, as Dag mentioned in the cython-devel thread, we could >> just deprecate the fields in Cython as well and place the burden on >> the user (and possibly issue warnings for their use). > > Something this list may not be aware of is that Cython 0.16 will support > a different mechanism for fast array access, implemented by Mark F.: > > cdef double[:, :] a = np.zeros((3, 3)) > > In this case, "a" is NOT a NumPy array but is coerced to a "typed memory > view", where Cython lays down semantics for the shape attribute etc. > > So I think the recommended approach for old code will be to move to this > syntax. This makes it less important to cook up fast NumPy-specific > .shape access; it could just revert to using the Python .shape > attribute, and then if there's a speed regression one could port the > code to the new memoryviews... > > Dag Sverre > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
