[Numpy-discussion] Please chime in on proposed methods for arrays
rlw at stsci.edu
Thu Mar 17 10:31:23 EST 2005
On Thu, 17 Mar 2005, Perry Greenfield wrote:
> On Mar 17, 2005, at 12:05 PM, konrad.hinsen at 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.
More information about the NumPy-Discussion