On Mar 16, 2008, at 5:28 AM, Dag Sverre Seljebotn wrote: > (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.
My thoughts too. > 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 __add__ won't be a member function, it'll be a c function. I was suggesting that PyObject's default __add__ is PyObject_Add. This is your "whatever that is" for untyped objects. >> 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..) I think we can avoid creating a full template compiler, but we'll need some way to access the parameters of a parameterized type in a sensible way. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
