[Numpy-discussion] Please chime in on proposed methods for arrays

Rick White rlw at stsci.edu
Thu Mar 17 10:31:23 CST 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.
					Rick





More information about the Numpy-discussion mailing list