On 9 May 2012 19:35, Robert Bradshaw <rober...@gmail.com> wrote: > On Tue, May 8, 2012 at 2:48 AM, Stefan Behnel <stefan...@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 exposers. >> 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@python.org > http://mail.python.org/mailman/listinfo/cython-devel _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
