Chris.Barker at noaa.gov
Tue Feb 8 10:28:47 CST 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:
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
> 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.
> 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.
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
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