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 now,
one that declares the item type before the brackets and one that declares
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...)
Dag
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 names,
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 ...)
Stefan
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
