[Cython] buffer syntax vs. memory view syntax

[Robert Bradshaw]

On Wed, May 9, 2012 at 12:09 PM, mark florisson
<markflorisson88 at gmail.com> wrote:
> On 9 May 2012 20:08, mark florisson <markflorisson88 at gmail.com> wrote:
>> 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.
>
> Although I suppose a typedef could help. But then it's harder to see
> the dtype without lookup up the typedef declaration. Oh well :)

One would only use this syntax when one wanted to use features from both.

>> 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 :)

Same here. I think part of the magic feel is due to the ambiguity; a
concrete and simple declaration of when it acts as an object and when
it doesn't could help here. Auto-coercion is well engrained into the
Cython language (and one of the big selling points) so I think that's
OK.

- Robert