[Numpy-discussion] @Dag re numpy.pxd
Sat Feb 11 15:45:08 CST 2012
On Sat, Feb 11, 2012 at 3:27 PM, mark florisson
> On 11 February 2012 20:31, Charles R Harris <email@example.com>
> > 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
> > 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
> > 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.
> > 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:
> 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
In the nditer, some functions are explicitly documented with a mechanism to
be called without holding the GIL.
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?
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion