[Cython] buffer shape incompatible with memoryview shape

[Stefan Behnel]

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.


> 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.
> 
> 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