I prototyped __getitem__ now: http://wiki.cython.org/enhancements/numpy/getitem
It looks feasible, but perhaps a bit daunting for the time-frame and "value-for-investment" compared to a simpler approach. Robert Bradshaw wrote: > On May 24, 2008, at 2:12 PM, Dag Sverre Seljebotn wrote: > >> I agree about time-frame being a danger. "Always scale up, not >> down." So >> might do a solution based on our own, custom __cgetitem__ first, and >> then try to generalize *that* afterwards if there's time. (But I'll >> still prototype __getitem__ just to see). > > No need to rename it __cgetitem__... So you propose that one keeps the name __getitem__, yet changes the interface completely compared to Python? (Don't pass slices, unpack the tuple prior to calling...) I don't see the benefit of keeping the name then, it only creates confusion... (re: the __add__ operators which doesn't behave like in Python). > Feasibility in determining the instantiated return type, and being > able to let "x = arr[5]" infer the type of x (based, of course, on > the type of arr). Ah, got it! Yes, that is a real problem. (Sorry.) > If the <object> coercion is compiler-inserted, then it will not have > any side effects that can't safely be ignored. Yes, I suppose. But also cdef object __getitem__(object self, object index) would be kind of hard to do type-inference on (would need to compile-time evaluate the contents and see...). What one "really" wants is something like cdef (self.dtype if (type(index) is not tuple or (not slice in [type(x) for x in index] and not Ellipsis in index) else object) __getitem__(self, item): ... Where the first (..) is the type declaration of __getitem__. I somehow don't feel too happy about that type declaration :-) So perhaps __cgetitem__ and __cgetslice__ it is (until you convince me the rename isn't needed...) -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
