Robert wrote:
> On May 22, 2008, at 11:35 AM, Dag Sverre Seljebotn wrote:
>>
>> Compile-time duck typing is not really just overloading, it is
>> overloaded
>> template methods, i.e. like this in C++:
>>
>> template <typename A, typename B>
>> A max(A a, B b) {...}
>>
>> (Unlike overloading, compile-time ducktyping has no Java equivalent).
>
> The last thing I want to do is head down a path of trying to
> reimplement C++. It has a lot of very powerful features, but they
> come at a cost. Perhaps if it can be pulled off smoothly enough
> though...Well, this was an attempt to take a step away from reimplementing C++, and do something more Pythonic. Anyway, all I really want is a way to built my __getitem__. This seemed less static and C++-ish than other alternatives I considered. The only real alternatives I see to some sort of compile-time ducktyping are: - Drop the __getitem__ syntax and rather add more fine-grained control (at the very least, reintroduce __getslice__ which Python is in the process of deprecating, probably add a whole bunch of other special functions too, or invent a fully new syntax). This is so that [] will be able to have different type signatures depending on the usecase. - From Stefan's thoughts on the buffer interface... I might also backport the buffer interface to 2.0 (i.e. we build in the structs etc. needed in the C file if needed) and implement a Cython native [] operator for buffers (and declare ndarray as exporting a buffer interface somehow etc.) Any other ideas? > It should come as no surprise that I don't like the keyword > "duckdef." On the other hand, automatically treating all def Indeed, I purposefully selected a distasteful keyword for the sake of the discussion, so that it wouldn't stick. As long as the feature is there somehow for __getitem__ to use I don't particularily mind syntax. One can make it very explicit first, then benchmark it etc. and see how it would fare if "def" was made automatically duck-typed, and perhaps make that change way, way later (when the stability of the scheme is proven). > functions in this way is scary (imagine several copies of a 1000 line > def function, and picking an arbitrary cutoff is, well, arbitrary). Well, C++ and Boost++ easily has 1000-line templates (or much more), containing multiple methods, being instantiated for multiple combinations of types (and passed to each other etc., creating very many combinations of types that must be expanded). The difference is that it is more explicit in C++. OTOH, in C++ there is not even an option to cut off anywhere (which we would have, if wanted). > It also seems a bit too magic for def functions--if anything this > should be applied to cdef functions instead. The "two kinds of C > types" has me worried too, and another concern is how to properly > deduce the return type. (Maybe given the inputs, it would re-analyze > the function and pick the type of the return statement?) I think having C types which behave in a way so that coercion back and forth to object would be a lossless, transparent operations would be progress in itself. Connecting it with a "ctypes" type hierarchy would not be unnatural. But I guess this is a seperate issue (which must be dealt with before duckdef can assume the role of def, but doesn't block duckdef through other, more explicit means before then). > Another option (just throwing it out, not convinced it's better) is > being explicit like > > cdef max(generic a, generic b): > return a if a >= b else b > > where "generic" is a special type. Or a keyword could be given as in Yes, I really, really like this one. If "generic" is not clear enough, "auto" is another option. Java has "?" for sort of the same job some places, however even if that is very clear it is also very ugly :-) BTW the future C++ specs will have "auto" IIRC, i.e. auto it = mycollection.begin() would declare it to be of the return type of begin(). Allowing "auto" in this way could be one incremental way towards type inference (allowing very easy development; one simply tries to use "auto" in more and more situations...). Function signatures would simply be the first place "auto" is allowed. > or it could be restricted to inline functions (where it would > obviously have the most use). -1. This would mean that def inline add(a, b): return a + b would handle overflowing conditions differently depending on whether the inline keyword is present or not. This would not exactly be obvious to the user. > The overloading mechanisms of PEP 3124 seem much cleaner than a list > of isinstances, and I would suggests perhaps that cdef functions > could be overloadable by default. But, as you said, this is somewhat > orthogonal. Keep in mind that with compile-time ducktyping, the only usecases for explicit overloading that remains are the exact same cases which currently shows up in type-less Python code, and where one currently has to use isinstance. This could be an argument for waiting with supporting explicit overloading until the time that Python decides to do so. However, these cases would tend to appear more often when writing wrapper code around C libraries (which use different names for different types, which you want to wrap using a single function name in Cython). Which is an argument in favor of explicit overloading. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
