[Cython] Cython 0.16 and ndarray fields deprecation

[mark florisson]

On 1 March 2012 16:18, Dag Sverre Seljebotn <d.s.seljebotn at astro.uio.no> wrote:
> 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.

To remain consistent with previous versions the former should be
supported and the latter would be a bonus (and it wouldn't be too hard
anyway).

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

+1 for that, just write &arr[0] as Sturla mentioned. The transition
should be trivial.

> 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
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel