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. > -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 > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
