[Cython] buffer syntax vs. memory view syntax

[Robert Bradshaw]

On Tue, May 8, 2012 at 2:48 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> mark florisson, 08.05.2012 11:24:
>>>>> Dag Sverre Seljebotn, 08.05.2012 09:57:
>>>>>>  1) We NEVER deprecate "np.ndarray[double]", we commit to keeping that in
>>>>>> the language. It means exactly what you would like double[:] to mean,
>>>>>> i.e.
>>>>>> a variable that is memoryview when you need to and an object otherwise.
>>>>>> When you use this type, you bear the consequences of early-binding things
>>>>>> that could in theory be overridden.
>>>>>>
>>>>>>  2) double[:] is for when you want to access data of *any* Python object
>>>>>> in a generic way. Raw PEP 3118. In those situations, access to the
>>>>>> underlying object is much less useful.
>>>>>>
>>>>>>   2a) Therefore we require that you do "mview.asobject()" manually; doing
>>>>>> "mview.foo()" is a compile-time error
>>> [...]
>>> Character pointers coerce to strings. Hell, even structs coerce to and
>>> from python dicts, so disallowing the same for memoryviews would just
>>> be inconsistent and inconvenient.
>
> Two separate things to discuss here: the original exporter and a Python
> level wrapper.
>
> As long as wrapping the memoryview in a new object is can easily be done by
> users, I don't see a reason to provide compiler support for getting at the
> exporter. After all, a user may have a memory view that is backed by a
> NumPy array but wants to reinterpret it as a PIL image. Just because the
> underlying object has a specific object type doesn't mean that's the one to
> use for a given use case. If a user requires a specific object *instead* of
> a bare memory view, we have the object type buffer syntax for that.

On the other hand, if the object type buffer syntax to be deprecated
and replaced by bare memory views, then a user-specified exporter is I
think quite important so that, e.g. when slicing NumPy arrays one gets
NumPy arrays back.

Is slicing the only way in which to get new memoryviews from old? If
this is the case, perhaps we could use a Python __getitem__ call with
the appropriate slice to create a new underlying object from the
original underlying object (only when needed of course). This is
assuming that the underlying object supports it.

> It's also not necessarily more efficient to access the underlying object
> than to create a new one if the underlying exporter has to learn about the
> mapped layout first.
>
> Regarding the coercion to Python, I do not see a problem with providing a
> general Python view object for memory views that arbitrary Cython memory
> views can coerce to. In fact, I consider that a useful feature. The builtin
> memoryview type in Python (at least the one in CPython 3.3) should be quite
> capable of providing this, although I don't mind what exactly this becomes.

I'd rather not make things global, but for memory views that were
created without an underlying object, having a good default (I'd
rather not have a global registry) makes a lot of sense.

- Robert