On 9 May 2012 20:08, mark florisson <markflorisso...@gmail.com> wrote: > On 9 May 2012 19:56, Robert Bradshaw <rober...@gmail.com> wrote: >> On Tue, May 8, 2012 at 3:35 AM, mark florisson >> <markflorisso...@gmail.com> wrote: >>> On 8 May 2012 10:47, Dag Sverre Seljebotn <d.s.seljeb...@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 :) > Buffer syntax should by no means deprecated in the near > future, but at some point it will be better to have one way to do > things, whether slightly magicky or more convoluted or not. Also, as > Dag mentioned, if we want fused extension types it makes more sense to > remove buffer syntax to disambiguate this and avoid context-dependent > special casing (e.g. np.ndarray and array.array). > >>> I wouldn't particularly mind something concise like 'm.obj'. >>> The AttributeError would be the case as usual, when a python object >>> doesn't have the right interface. >> >> Having to insert the .obj in there does make it more painful to >> convert existing Python code. > > 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 :) > >> - 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
