[Numpy-discussion] Ransom Proposals

[Christopher Barker]

Sasha wrote:

> If this is the case, it is probably better to remove the reshape
> function altogether. 

+1

I'm a big fan of OO syntax -- it really cleans up name spaces.

Colin J. Williams wrote:
> Perhaps most of the functions could be in a compatibility module, which 
> the user would import as needed, with most cases defined as something like:
> reshape(arr, d1, d2, ...)= numpy.ndarray.reshape(arr,d1, d2, ...)

+1

Ed Schofield wrote:
> I'm now a fan of method interfaces in Python.  One reason is that, with 
> .reshape(), .sum() etc. as methods, rather than functions, it's possible 
> for me to make the behaviour of SciPy's sparse matrices highly 
> consistent with NumPy's arrays and matrices

Another good reason for an OO interface!

Bill Baxter wrote:
> And maybe they'd be right to want a functional interface, too:  
> http://www.gotw.ca/gotw/084.htm

I can see that this applies to sin(), cos() etc, but from that doc:

"""Prefer to make it a member if it needs access to internals:"""

I think reshape() and friends fall into this category.

I always thought there was an odd argument in the old Numeric docs:

"""
Choosing functions means that the same procedures can be applied to 
arbitrary python sequences, not just to arrays. For example, while:

 >> transpose([[1,2], [3,4]])

works just fine,

 >> [[1,2], [3,4]].transpose()

can't work.
"""

For me, that argument would only hold if transposing a list returned a 
transposed list, but it doesn't: it returns an array. What's going on 
under the hood is something like:

return asarray(TheInput).transpose()

The user can not use transpose() without committing to arrays, so why 
not just have them make the asarray call. All you're doing is creating a 
less explicit interface and cluttering the name space to save some typing.

As far I'm concerned, most functions that have a signature like:

Array = function(Array, whatever)

should probably be methods. I know there's history to consider, so I 
don't actually expect this to change, and I'm very happy with the new 
methods introduced by numpy.

-Chris





-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov