[Cython] buffer syntax vs. memory view syntax

mark florisson markflorisson88 at gmail.com
Wed May 9 20:45:48 CEST 2012

On 9 May 2012 19:35, Robert Bradshaw <robertwb at gmail.com> wrote:
> 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.

You can also use newaxis indexing or transpose the view, but those are
the only ways to change the view I think. I like the idea quite a bit,
as the callback has no sane way of getting registered. For newaxes we
could pass in None in the right places to __getitem__, as for
transpose, the 'T' attribute works for numpy, I don't know about other

>> 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
> _______________________________________________
> 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