[Numpy-discussion] metadata and metabehavior for arrays (for scipy.base or Numeric3)

Sebastien.deMentendeHorne at electrabel.com Sebastien.deMentendeHorne at electrabel.com
Thu Apr 7 02:54:57 CDT 2005

> > Why not have the ability to ask the name of an ufunc to be able to 
> > dispatch on it ?
> That's already possible.
> > What about :
> >
> > object.__unary__(cos, mode = "reduce")
> > object.__binary__(cos, other, mode = "reduce")
> What does "reduce" mode mean for cos?
> What does a binary ufunc in reduce mode do with its second argument?

raise a ValueError :-)
It was an example of a way to pass argument, the focus was on cos.reduce or "cos.reduce" or cos, "reduce".

> > However, for binary operations, how it the call dispatched 
> if one of 
> > the operand is of a type while the other is another type ? This 
> > problem is related to multimethods 
> > http://www.artima.com/weblogs/viewpost.jsp?thread=101605
> No need to be innovative: Python always dispatches on the first 
> argument, and everybody is familiar with that approach even though it 
> isn't perfect. If Python 3000 has multimethods, we can still adapt.

The problematic is related to multimethods, the implementation should not be specially related.

In an a call like object.__binary__(add, other), if other is not of the same type of object, the latter could throw an exception as ImplementationError to give the hand to other.__binary__(add, binary) or to other.__binary__(radd, binary) or similar (i.e. those expressions may not make sense but the
idea is to have a convention to give the hand to the other operand, python does this already when one overloads an operator like __add__ (__radd__)).
So if we can keep this same protocol for binary ufunc, that would be great.

Otherwise, I think it is not that a big deal.


This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake please let us know by reply and then delete it from your system; you should not copy it or disclose its contents to anyone. All messages sent to and from Electrabel may be monitored to ensure compliance with internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. Anyone who communicates with us by email is taken to accept these risks.


More information about the Numpy-discussion mailing list