[Cython] Cython 0.16 and ndarray fields deprecation

[Dag Sverre Seljebotn]

On 03/01/2012 04:03 AM, mark florisson wrote:
> 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.

So you are saying we (somehow) stick with supporting "arr.shape[0]" in 
the future, and perhaps even support "print arr.shape"? (+ arr.dim, 
arr.strides). Exactly how we could figure out at PyCon.

I'm anyway leaning towards deprecating arr.data, as it's too different 
from what the Python attribute does.

Reason I'm asking is that I'm giving a talk on Saturday, and I don't 
want to teach people bad habits -- so we must figure out what the bad 
habits are :-) (I think this applies for the PyCon poster as well...)

[1] PyData workshop at Google's offices in Mountain View; the event was 
open for all but now it is full with a long waiting list, which is why I 
didn't announce it. http://pydataworkshop.eventbrite.com/

Dag