Re: [Numpy-discussion] Release of 1.0b5 this weekend

[David M. C. <co...@ph...>]

On Tue, 29 Aug 2006 13:25:14 -0600
"Charles R Harris" <cha...@gm...> wrote:

> Hi Fernando,
> 
> On 8/29/06, Fernando Perez <fpe...@gm...> wrote:
> >
> > On 8/29/06, Charles R Harris <cha...@gm...> wrote:
> >
> > > Speaking of features, I wonder if more of the methods should return
> > > references. For instance, it might be nice to write something like:
> > >
> > >  a.sort().searchsorted([...])
> > >
> > > instead of making two statements out of it.
> >
> > +1 for more 'return self' at the end of methods which currently don't
> > return anything (well, we get the default None), as long as it's
> > sensible.  I really like this 'message chaining' style of programming,
> > and it annoys me that much of the python stdlib gratuitously prevents
> > it by NOT returning self in places where it would be a perfectly
> > sensible thing to do.

-1, for the same reasons l.sort() doesn't (for a list l). For lists, the
reason .sort() returns None is because it makes it clear it's a mutation.
Returning self would make it look like it was doing a copy.

> My pet peeve example: a.reverse()
> 
> I would also like to see simple methods for "+=" operator and such. Then one
> could write
> 
> x = a.copy().add(10)

There are:
x = a.copy().__add__(10)

or, for +=:
x.__iadd__(10)

> One could make a whole reverse polish translator out of such operations and
> a few parenthesis. I have in mind some sort of code optimizer.

It wouldn't be anymore efficient than the other way. For a code optimizer,
you'll either have to parse the python code or use special objects (much like
numexpr does), and then you might as well use the operators.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...