On May 24, 2008, at 10:16 AM, Dag Sverre Seljebotn wrote: > Robert wrote: >> Perhaps put an example of a __getitem__ method that uses this >> feature. It seems mostly this could be handled with plain old >> function overloading, but this would be a nice feature to have in and >> of itself. > > Yes, will do that, but for now I'll scetch the problems with plain old > overloading and how this proposal (parameter polymorphism/compile-time > duck typing) solves it. > > Problem 1: The return type is different depending on the assumptions > placed on the object (i.e. if dtype=uint8 then single-item indexing > should > return uint8). Traditional overloading doesn't really solve this -- > or if > you overload on method return type, you'd have a possibility but it > would > mean manually copying the method for every single return type... > > Problem 2: Consider these calls and their translation to more explicit > psuedo-code: > > cdef ndarray[dtype=uint8, ndim=3] arr = ... > arr[1, 2, 3] => arr.__getitem__((1, 2, 3)) > arr[1:2, ...] => arr.__getitem__((slice(1, 2, None), Ellipsis)) > > Now, the first lookup should return uint8, while the second one should > return a new object (a new array view) -- yet, both arguments are > of the > type "object". > > In order to solve these problems, one could start to create > complicated > solutions like allowing "self.dtype" as a return type in the method > signature if an assumption is placed on self, specify "nested > types" (ie. > tuple(int, int, int)), with a following combinatorial explosions in > manual > overloads one needs to create) etc. etc.
Ah, but in this case it seems much simpler (from the users perspective) to resolve arr[1,2,3] as __getitem__(1,2,3) and let function overloading handle this the normal way. BTW, in terms of focus, I think handling slicing is much lower on the priority list than a lot of other things (the relative gain here is much smaller). > However, just making both the return type and parameter "generic" > seems a > much simpler, more readable solution that will work out to the same > thing. > Then the type system doesn't get in the way, and one can write a > single > __getitem__ and leave the real issues to "optional" optimizations. > > (In order for this to work there's a small hitch: One must support > code > like this: > > cdef generic get_something(as_str): > if as_str: return "asdf" > else: return 3432 > > This can be fixed simply by having return type mismatches for > instantiated > generics converted into runtime errors rather than halt > compilation, this > emulates Python behaviour nicely.) So here "generic" would become the more general of the two, i.e. an object. For generic inline functions, would it get optimized away (i.e. if one knew as_str at compile time, it would know the return type exactly?) - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
