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