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.
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.)
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
