On Sat, Feb 11, 2012 at 3:27 PM, mark florisson <markflorisso...@gmail.com>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). > In the nditer, some functions are explicitly documented with a mechanism to be called without holding the GIL. http://docs.scipy.org/doc/numpy/reference/c-api.iterator.html#NpyIter_Reset Internally, this produces a generic message that doesn't include the normal user-friendly context, but is still better than just spitting out "runtime error." Is this style good for cython, or do you have any other ideas of how to support nogil while adding the possibility of raising errors? -Mark > 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). > _______________________________________________ > 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
