On Sat, Feb 11, 2012 at 2:57 PM, mark florisson <markflorisso...@gmail.com>wrote:
> On 11 February 2012 21:45, Mark Wiebe <mwwi...@gmail.com> wrote: > > 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? > > That's a nice way to support it. Cython itself often acquires the GIL > in the exception case in nogil contexts, sets the exception, and then > takes the error path. The problem with that is of course overhead, but > it should usually do it for exceptional conditions only (i.e. things > that normally should not occur, so not for normal conditions like > raising StopIteration etc). > > However, we also want to get rid of the 'except' clause and in general > need a way to check for error conditions for functions that have > non-object return types and no known exceptional values for those > types. For externally shared Cython functions this may mean exporting > multiple versions with different ABIs, the point being that the user > will not have to care, as taking the address or making it public would > still give the normal C ABI compatible version of the function. > > Anyway, I digress. For NumPy that seems like a good thing to do. > Perhaps it would be even nicer to pass in a pointer to npy_errorstate > or some such, which holds complete error information. Then, with the > GIL one could call something like > npy_raise_from_errorstate(&my_error_state). Functions could easily set > the error type as well in there through a borrowed reference. > > Another thing to worry about, arr->data can be NULL. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion