[Numpy-discussion] @Dag re numpy.pxd

[Charles R Harris]

On Sat, Feb 11, 2012 at 2:57 PM, mark florisson
<markflorisson88 at gmail.com>wrote:

> On 11 February 2012 21:45, Mark Wiebe <mwwiebe at gmail.com> wrote:
> > On Sat, Feb 11, 2012 at 3:27 PM, mark florisson <
> markflorisson88 at gmail.com>
> > wrote:
> >>
> >> On 11 February 2012 20:31, Charles R Harris <charlesr.harris at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120211/8549c2fb/attachment.html>