[Cython] Draft for operator overloading

[Robert Bradshaw]

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