[Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
Wed Apr 9 13:27:04 CDT 2008
Sorry to be late on this thread, but I was out of town, and I do feel
strongly about this issue.
Gael Varoquaux wrote:
> For the beginner, "from numpy.all import *" is more confusing than "from
> numpy import *" (which is already confusing).
except that the beginner, nor anyone else, should ever use "import *"
> I know namespace are good things, but the beginner struggles with them.
> This is why I used the "import *" in my above examples.
You're better off with a good foundation -- really. And particularly for
a beginner, knowing what comes from numpy, and what from python (or
other packages) is a "good thing".
It's a mixed bag, but I like namespaces a lot -- there's a lot to be
said for thinking: I need some stats, an doing something like:
from numpy.stats import stats
That being said, having a numpy.all namespace has its uses, particularly
for interactive use, but let's not make it the default.
Look at history here:
Everyone used to do "from Numeric import *", now many (most?) folks use
the numpy namespace, with something like "import numpy as N".
Matplotlib started out with a Matlab like: "from pylab import *", now
there is a separate namespace for plotting, etc, and a movement towards
using separate namespaces.
"Namespaces are one honking great idea -- let's do more of those!"
That's "more", not "fewer"
Gael Varoquaux wrote:
> Convention are important, especially in coding.
This is really, really important. What if we all used a different name
for "self?" -- just as correct, but it would be a lot harder to
understand other's code.
I really don't get the reluctance -- EVERY major package I've worked
with has moved AWAY from "import *" (numpy, wxPython, matplotlib, ...).
We should never, never, recommend it to beginners. Period. And it would
be very nice to use a standard. I use "import numpy as N", but would be
quite happy to use "np" or "nx", or anything else short that becomes a
> IMHO the
> pylab option is quite nice: matplotlib is nice and modular, but pylab has
> it all. Use whichever you want.
I disagree -- with pylab and numpy, there is constant confusion from
folks as they move past the beginner stage -- "where did that function
come from?", "What do I have to change now that I'm embedding my MPL
code in a GUI?"
"There should be one-- and preferably only one --obvious way to do it."
Maybe there is a large population of folks that never do move past the
beginner stage -- but I say -- let then use Octave! I use Python
specifically because it's a more sophisticated language than Matlab.
> The only thing
> namespaces solve is name collisions imho.
The other one is readability -- I like knowing where things come from,
and what that have to do with. This is really an augment against "import
*", but it applied to hierarchical namespaces too -- you can see the
structure in the code, -- I like that.
> I don't believe that the
> current numpy has too many names in its basic namespace,
It's a little too big, rather than a lot too small though -- remember
this thread started from "where do we put financial functions".
> and it
> already has split out some things into subpackages (fft, random,
> linear algebra) that have such a potential.
exactly -- so numpy.finance fits right in...
> 3) Some don't like the bloat (in disk space or download sizes) of
> adding things to numpy. In my case, as long as the addition doesn't
> make installations any more difficult I don't care.
+1 Easy of installation is far more important than download size.
Brian Granger wrote:
> Simply putting things into
> numpy because of convenience (numpy is easier to install) only
> encourages people to never install or use scipy.
Actually it's worse -- it discourages us from making scipy easier to
install. I still don't use it.
But we can save most of this for 1.1 (or 2.0, or...)
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
More information about the Numpy-discussion