[Cython] Cython 0.16 and ndarray fields deprecation

[mark florisson]

On 29 February 2012 17:57, Dag Sverre Seljebotn
<d.s.seljebotn at astro.uio.no> wrote:
> 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[0]" is often just fine, but currently one is in a situation
>>> where one must either write "(<object>arr).shape[0])" or
>>> "np.PyArray_DIMS(arr)[0]", 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...

I would personally prefer either cdef nogil extension class properties
(needs compiler support) or just special-casing in the compiler, which
shouldn't be too hard I think. Warnings would be a first step, but the
linkage of ndarray attributes to C attributes is really an
implementation detail, so it's better to keep supporting the
attributes correctly.

> Dag
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel