[Cython] Cython 0.16 and ndarray fields deprecation
Dag Sverre Seljebotn
d.s.seljebotn at astro.uio.no
Wed Feb 29 18:57:13 CET 2012
On 02/29/2012 09:42 AM, Stefan Behnel wrote:
> Dag Sverre Seljebotn, 29.02.2012 18:06:
>> I'm wondering what the best course of action for deprecating the shape
>> field in numpy.pxd is.
>> The thing is, currently "shape" really gets in the way. In most situations
>> it is OK with slow access to shape through the Python layer, and
>> "arr.shape" is often just fine, but currently one is in a situation
>> where one must either write "(<object>arr).shape)" or
>> "np.PyArray_DIMS(arr)", or be faced with code that isn't
>> forward-compatible with NumPy.
> Can Cython emulate this at the C layer? And even your work-around for the
> Python object access looks more like a Cython bug to me. I wouldn't know
> why that can't "just work". It usually works for other undeclared Python
> attributes of "anything", so it might just as well be made to work here.
Well, the problem is that shape is currently declared as a C field. It
is also available as a Python attribute. Usually the user doesn't care
which one is used, but the C field is declared for the few cases where
access is speed-critical.
Though even with current NumPy, I find myself doing "print
(<object>arr).shape" in order to get a tuple rather than a Py_ssize_t*...
>> It would really be good to do the transition as fast as possible, so that
>> all Cython code eventually becomes ready for upcoming NumPy releases.
> But it previously worked, right? It's just no longer supported in newer
> NumPy versions IIUC? If that's the case, deleting it would break otherwise
> working code. No-one forces you to switch to the latest NumPy version,
> after all, and certainly not right now. A warning is much better.
It previously worked, but it turns out that it was always frowned-upon.
I didn't know that when I added the fields, and it was a convenient way
of speeding things up...
More information about the cython-devel