(Leaving pxd/pyx to be dealt with later, it's becoming too much at once.) > And then the default __operator__() would get translated to the > Python operation (i.e. PyNumber_Add)?
Note: I didn't intend the C++ syntax and Python syntax to be competing alternatives, I believe them to be complementary. I believe the reason we couldn't make any headway on operator syntax is because there's a distinction between declaring what is available on types in C++ directly (not C, no operator overloading there...) and thus must have C++ access code generated, versus "extra" Cython functionality (including redirecting operators to function calls in that functionality). The full chain of dealing with " a + b" would be: - If it is am "untyped" Python object, do as today, whatever that is. - Otherwise: - See if a.__add__ exists, if so, generate code to call it (as a regular C member function, whether __add__ has been declare cdef or def or pdef or whatever - have the same semantics as with other member functions, also with respect to pxd and pyx) - Then, see if a native operator is supported. This can be because it is a pointer or number, or because "operator+" has been declared as available on the type (latter in C++ mode only) - Otherwise, FAIL > The compile-time type and runtime type are two distinct objects, and > will have different methods and members. There may not even be a 1-1 > correspondence. And it would be unsafe at compile time to evaluate > type(x) for most x (e.g. one could get a subclass). Good point. Need to think more. C++ templates does deal with this exact problem, but the syntax might not fit us... Basically, that's what all this is about right... NumPy support needs template support. Was just hoping to avoid the functional programming style (and especially hoping to avoid creating a full template compiler..) Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
