[PEP draft 2] Adding new math operators

[Travis Oliphant]

> Some historical remarks from NumPy development:

[snipped]  but recommended reading for some who may be unfamiliar with the
debates that have come before...

> Now we *are* discussing changes to the Python core, so why not go
> for the "grand unification":
> 
> 1) Add array/matrix objects to the core distribution.

Trying to do this.  If you have significant comments on how to do this
please let me know.  Right now the plan is to put in this objects as
Python classes with supporting C code (borrowed heavily from the current
implementation).  I should write a PEP, but time...

> 2) Define methods for them and implement them for the scalar types
>    as well (the implementation would in practice be shared, of course).

This makes definining methods for arrays much more prone to argument, but
it could be done.  In the current skeleton, array classes have only a few
"non-hidden" methods.

> 3) Add the missing scalar types corresponding to single-precision
>    float and complex.

I've brought this up before and wouldn't mind seeing it, but lately I've
considered that we might be more successful if we just get rank-0 arrays
from ceasing to be silently "upgraded" to Python scalars.  

One thing to consider, is that if and when we get the arrays into the
Python core, the only reason for the "present Python scalars" is reducing
the overhead of the array class for every integer since --- they are in
all ways equivalent to rank-0 arrays (not currently the case, but it could
be).  

It seems to me that a useful solution to the type/class dichotomy which
has come out of my thinking about what to do with NumPy is to define no
types at all and make everything classes. 


> 4) Make scalars behave like rank-0 arrays in every respect (i.e.
>    having a shape attribute etc.)

The other side of this is what I've been trying to do with NumPy and that
is make rank-0 arrays behave in every respect like Python scalars. 

I'm definitely in favor of this.  In fact, I think these ideas are much
more important than the proposed new operators.  The problems caused by
this lack of unification seem more important to me than the syntatic
difficulties of matrix multiplication as a function call.

Travis Oliphant