[Cython] buffer shape incompatible with memoryview shape

[mark florisson]

On 21 June 2012 14:34, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Dag Sverre Seljebotn, 21.06.2012 15:06:
>> On 06/21/2012 02:59 PM, Stefan Behnel wrote:
>>> Dag Sverre Seljebotn, 21.06.2012 14:05:
>>>> On 06/21/2012 01:36 PM, Stefan Behnel wrote:
>>>>>> On 06/21/2012 10:59 AM, Stefan Behnel wrote:
>>>>>>> I find this worth fixing for 0.17:
>>>>>>>
>>>>>>> http://trac.cython.org/cython_trac/ticket/780
>>>>>>
>>>>> I ran into this when I gave a Cython+NumPy course and this was the first
>>>>> thing that the attendants tried when I asked them to validate that two
>>>>> input arrays have the same size before adding them. It's the one obvious
>>>>> way to do it, and it fails miserably. I think it should be fixed, and I
>>>>> think it should be fixed soon because it feels really low-level and
>>>>> complicated, especially to new users.
>>>>
>>>> Can you clarify a bit -- did you give this course using np.ndarray[double,
>>>> ndim=2], or double[:, :]? They're really very separate under the hood and
>>>> the fix is different.
>>>>
>>>> Or, did you actually use object[double, ndim=2] like in the bug report?
>>>> (Did me and Mark get around to propose deprecating this one on the list?)
>>>
>>> IIRC, we used object[double, ndim=2] for both and I also tried it with a
>>> memory view as in the bug report. I thought that using "object" was the
>>> preferred way to do it? At least, it doesn't restrict the type of the
>>> buffer exporter, which I consider a good thing.
>>
>> That's a very theoretical argument as NumPy arrays are in practice the only
>> exporter.
>
> Except for, say, bytes objects, array.array and user implemented types,
> that is. lxml has buffer support for its serialised XSLT output, for example.
>

You can already easily obtain a pointer from a bytes object, which is
already 1d anyways :) Whether buffers on array.array are useful is
still questionable given their variably-sized nature.

>> I always teach np.ndarray[double...]. I've never told anyone about
>> object[...], I don't think it's in much use. For starters it's going to be
>> horribly inefficient unless you also add "mode='strided'" within the brackets.
>
> Ah, good to know.
>
>
>> My proposal (and Mark's I think) is:
>>
>> Since the memoryviews will neatly cover the general exporter case, and
>> since the [] syntax is much overloaded already (used for C++ templates
>> too), we should deprecate object[...] no matter what else happens.
>

I agree with deprecating the object[] syntax, I think memoryviews
should prove themselves a bit more for e.g. 0.17, before we start
deprecating np.ndarray.

>> Depending on what's decided for np.ndarray[...], we have:
>>
>> Case A): Deprecate both np.ndarray[...] and object[...]
>>
>> Case B): Only deprecate object[...], keep np.ndarray[...] (e.g., through a
>> decorator used in numpy.pxd on the ndarray type). So rather than having a
>> trailing [] mean buffers unless it means something else (like C++
>> templates), we instead make np.ndarray a "template", through special
>> compiler support.
>
> What's the point in technically deprecating them if we can't remove them
> without breaking code? Wouldn't it be better to deprecate them only in the
> docs?
>
> Stefan
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel