On Wed, May 9, 2012 at 12:09 PM, mark florisson <markflorisso...@gmail.com> wrote: > 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 :)
One would only use this syntax when one wanted to use features from both. >> 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 :) Same here. I think part of the magic feel is due to the ambiguity; a concrete and simple declaration of when it acts as an object and when it doesn't could help here. Auto-coercion is well engrained into the Cython language (and one of the big selling points) so I think that's OK. - Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
