[Numpy-discussion] Numeric3

Chris Barker Chris.Barker at noaa.gov
Tue Feb 8 10:28:47 EST 2005

Travis Oliphant wrote:

> Very loosely a matlab or IDL-like environment.  Nobody has really 
> defined what it means to be a MATLAB-like environment. 

Well, I HOPE it means:

An environment in which you can do most of what you can do with MATLAB, 
just as easily, but with a more pythonic approach. I wanted a MATLAB 
like language, I'd use MATLAB (or maybe Octave or Psilab).

> from scipy import *

And I'd like to see this deprecated.

> makes a lot of command-like interaction possible.

I think command-line interaction is quite possible without import *. I'm 
actually kind of disappointed in Numeric, from this perspective. I 
always used to use "from Numeric import *", because Numeric was designed 
to be used this way, which I think is a shame. Far more should be 
methods, rather than functions. For example, there are a bunch of 
functions that take an array as the first argument:

Numeric.take(a, i)

Why in the world is this not:


If it (and many other functions) were methods, there would be far less 
need for "import *" (I do use import "Numeric as N" to save typing)

In the docs, for many years, there has been the explanation that the 
above approach allows people to use any python sequence, rather than 
just arrays, with these functions. I find that that buys me very little. 
The example given in the docs (a few years ago, is it still there?) is 

at = Numeric.transpose(a)

can be passed a Python sequence that has an appropriate structure. 
However, internally, what's going on is something like:

b = Numeric.asarray(a)
at = Numeric.transpose(b)

Is it really so hard to write that extra line? Remember that transpose() 
always returns a NumPy array, regardless of the type of the input. How 
often are you using arbitrary python sequences anyway? In my case, I am 
never using arbitrary python sequences unless I'm writing a function or 
method for an external API, in which case, I almost always put an 
Numeric.asarray() call in at the top.

Well, this turned out to be too much of a rant, but the basic gist was: 
let's make SciPy Pythonic, rather than Matlaby. And the same goes for 


   Is this seen as
> MATLAB-like?
> I guess right now, scipy is trying to bring lots of modules under a 
> common naming convention.
> I think the goals of scipy are very much what people are talking about 
> here.   SciPy ultimately becomes what its users and developers want it 
> to become.   That is why I'm so unclear as to why we have not received 
> more support in its development --- even in the way of ideas as to how 
> to make it better --- until the great ideas that have been suggested on 
> this list recently.
> -Travis
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Christopher Barker, Ph.D.
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

More information about the NumPy-Discussion mailing list