[SciPy-dev] Suppressing of numpy __mul__, __div__ etc

Dmitrey tmp50 at ukr.net
Thu Dec 17 08:28:02 EST 2009


От кого: Sebastian Walter <sebastian.walter at gmail.com>  
  
  1) From an abstract point of view, oofun should be a data type.  
And the container of choice would be a numpy.array of dtype ofun, not  
of dtype object.  
  
so array([1,2,3],dtype=float) * oofun(2) should return  
array([2,4,6],dtype=returntype(oofun,float))    
What do you mean under oofun(2) ?!  
oofun is  
array([1,2,3],dtype=float) * oofun_instance should return result of type oofun and nothing else.  
Same to other classes - SAGE, polinomials, etc.  
  
  When ndarray.__mul__(self, other) is called, and other is a container,  
it should simply check if it knows how to handle that container.  
If ndarray doesn't know, it should call the other.__rmul__ and hope  
that `other` knows what to do.  
  
E.g.  
  
class matrix:  
iscontainer = True  
....  
  
class ndarray:  
  
def __mul__(self, other):  
if other.iscontainer:  
if not know_what_to_do_with(other):  
other.__rmul__(self)  
  
else:  
do what is done now: treat other as dtype=object  
  
then array * matrix  
would call the ndarray.__mul__ operator  
it then realizes that matrix is a container but ndarray doesnt know  
what to do with it. It would therefore call matrix.__rmul__     
  If other is not a container it is treated as object and we would get  
the current behaviour. This would allow to stay backward compatible.    
As for me, I dislike the idea - it's too complicated, and some containers sometimes could want to take operations priority, using their __rmul__  etc instead of ndarray __mul__ etc.  
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091217/29c1567d/attachment.html>


More information about the SciPy-Dev mailing list