[Cython] buffer syntax vs. memory view syntax

mark florisson markflorisson88 at gmail.com
Wed May 9 21:08:07 CEST 2012


On 9 May 2012 19:56, Robert Bradshaw <robertwb at gmail.com> wrote:
> On Tue, May 8, 2012 at 3:35 AM, mark florisson
> <markflorisson88 at gmail.com> wrote:
>> On 8 May 2012 10:47, Dag Sverre Seljebotn <d.s.seljebotn at astro.uio.no> wrote:
>>>
>>> After some thinking I believe I can see more clearly where Mark is coming
>>> from. To sum up, it's either
>>>
>>> A) Keep both np.ndarray[double] and double[:] around, with clearly defined
>>> and separate roles. np.ndarray[double] implementation is revamped to allow
>>> fast slicing etc., based on the double[:] implementation.
>>>
>>> B) Deprecate np.ndarray[double] sooner rather than later, but make double[:]
>>> have functionality that is *really* close to what np.ndarray[double]
>>> currently does. In most cases one should be able to basically replace
>>> np.ndarray[double] with double[:] and the code should continue to work just
>>> like before; difference is that if you pass in anything else than a NumPy
>>> array, it will likely fail with a runtime AttributeError at some point
>>> rather than fail a PyType_Check.
>>
>> That's a good summary. I have a big preference for B here, but I agree
>> that treating a typed memoryview as both a user object (possibly
>> converted through callback) and a typed memoryview "subclass" is quite
>> magicky.
>
> With the talk of overlay modules and go-style interface, being able to
> specify the type of an object as well as its bufferness could become
> more interesting than it even is now. The notion of supporting
> multiple interfaces, e.g.
>
> cdef np.ndarray & double[:] my_array
>
> could obviate the need for np.ndarray[double]. Until we support
> something like this, or decide to reject it, I think we need to keep
> the old-style syntax around. (np.ndarray[double] could even become
> this intersection type to gain all the new features before we decide
> on a appropriate syntax).

It's kind of interesting but also kind of a pain to declare everywhere
like that. Buffer syntax should by no means deprecated in the near
future, but at some point it will be better to have one way to do
things, whether slightly magicky or more convoluted or not. Also, as
Dag mentioned, if we want fused extension types it makes more sense to
remove buffer syntax to disambiguate this and avoid context-dependent
special casing (e.g. np.ndarray and array.array).

>> I wouldn't particularly mind something concise like 'm.obj'.
>> The AttributeError would be the case as usual, when a python object
>> doesn't have the right interface.
>
> Having to insert the .obj in there does make it more painful to
> convert existing Python code.

Yes, hence my slight bias towards magicky. But I do fully agree with
all opposing arguments that say "too much magic". I just prefer to be
pragmatic here :)

> - Robert
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel


More information about the cython-devel mailing list