[Cython] buffer syntax vs. memory view syntax

[Stefan Behnel]

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.

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.


> Also, if you don't allow coercion from python, then it means they also
> cannot be used as 'def' function arguments and be called from python.

Coercion *from* Python is not being questioned. We have syntax for that,
and a Python memory view wrapper can easily be unboxed (even transitively)
through the buffer interface when entering back into Cython.

Stefan