On May 24, 2008, at 2:58 PM, Dag Sverre Seljebotn wrote: > 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...
I'm thinking of extending the semantics (note, for inline functions only, otherwise none of this optimization can happen), and not in a way that is backwards incompatible. __getitem__(self, [object] index) will always be available, and always called for non-inlined code. > (re: the __add__ operators which doesn't behave like in Python). Yes, this is a blemish... >> 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 :-) Me either... > So perhaps __cgetitem__ and __cgetslice__ it is (until you convince > me the > rename isn't needed...) You're whole (..) can be encoded in the argument signature (fixing the number of arguments, which I'll admit is undesirable). The "tuple" representing the indices never gets created or used in this case, which makes things much clearer. Otherwise, I still don't see how you're going to unpack the tuple argument in the generic case without resorting to Python tuples. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
