[Cython] buffer syntax vs. memory view syntax
Dag Sverre Seljebotn
d.s.seljebotn at astro.uio.no
Mon May 7 18:03:44 CEST 2012
On 05/07/2012 06:00 PM, Dag Sverre Seljebotn wrote:
> On 05/07/2012 04:16 PM, Stefan Behnel wrote:
>> Stefan Behnel, 07.05.2012 15:04:
>>> Dag Sverre Seljebotn, 07.05.2012 13:48:
>>>> BTW, with the coming of memoryviews, me and Mark talked about just
>>>> deprecating the "mytype[...]" meaning buffers, and rather treat it as
>>>> np.ndarray, array.array etc. being some sort of "template types".
>>>> That is,
>>>> we disallow "object[int]" and require some special declarations in the
>>>> relevant pxd files.
>>> Hmm, yes, it's unfortunate that we have two different types of syntax
>>> one that declares the item type before the brackets and one that
>>> it afterwards.
>> I actually think this merits some more discussion. Should we consider the
>> buffer interface syntax deprecated and focus on the memory view syntax?
> I think that's the very-long-term intention. Then again, it may be too
> early to really tell yet, we just need to see how the memory views play
> out in real life and whether they'll be able to replace
> np.ndarray[double] among real users. We don't want to shove things down
> users throats.
> But the use of the trailing- syntax needs some cleaning up. Me and
> Mark agreed we'd put this proposal forward when we got around to it:
> - Deprecate the "object[double]" form, where [dtype] can be stuck on any
> extension type
> - But, do NOT (for the next year at least) deprecate np.ndarray[double],
> array.array[double], etc. Basically, there should be a magic flag in
> extension type declarations saying "I can be a buffer".
> For one thing, that is sort of needed to open up things for templated
> cdef classes/fused types cdef classes, if that is ever implemented.
> The semantic meaning of trailing  is still sort of like the C++
> meaning; that it templates the argument types (except it's lots of
> special cases in the compiler for various things rather than a
> Turing-complete template language...)
s/argument types/base type/
>> The words-to-punctuation ratio of the latter may hurt the eyes when
>> encountering it unprepared, but at least it doesn't require two type
>> of which the one before the brackets (i.e. "object") is mostly useless.
>> (Although it does reflect the notion that we are dealing with an object
>> here ...)
>> cython-devel mailing list
>> cython-devel at python.org
> cython-devel mailing list
> cython-devel at python.org
More information about the cython-devel