On Thu, 17 Mar 2005, Perry Greenfield wrote:
On Mar 17, 2005, at 12:05 PM, konrad.hinsen@laposte.net wrote:
I agree. What I suggested is that there should be methods as well as functions, and that the ufuncs should call the methods, such that
Numeric.sin(x)
would simply become syntactic sugar for
x.sin()
whatever the type of x. But I don't expect to see x.sin() in application code, it's just a convenient way of implementing sin() in new classes and subclasses. Actually, x.__sin__() would be a more pythonic choice of method name.
Konrad.
It would be hard to imagine not allowing the functional form. Users would think we were crazy. (And they'd be right ;-)
I think the suggestion that ufuncs should call methods behind the scenes is a bad idea. It just doesn't makes much sense to me. Doesn't this imply that you have to decorate array objects with another method every time someone adds another 1-argument ufunc? Even if you argue that you only want the methods for some standard set of ufuncs, it seems like a lot of baggage to pile into the array objects. I like the arc hyperbolic sine function, but I can't see why I would expect an array to have either a method x.asinh() or, worse, x.__asinh__()! Maybe I'm misunderstanding something here, but this just sounds like a way to bloat the interface to arrays. Rick