[Cython] Cython 0.16 and ndarray fields deprecation

[Dimitri Tcaciuc]

On Fri, Mar 2, 2012 at 8:29 AM, mark florisson
<markflorisson88 at gmail.com> wrote:
> 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.

If there's a confusion due to .data already having a certain meaning
with the python attribute, perhaps it would make sense to have an
attribute with a different name, eg. .ptr or .voidptr ? IMHO writing
&arr[0] looks like a workaround of some kind. Like, when in C you had
something like a 2d array and you'd need to interpret it as a 1d array
you'd write &arr[0][0], but C array syntax doesn't support attributes
which you can add here. Unless of course the idea is to make arrays to
behave and look exactly like C counterparts.

Dimitri.

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