Robert Kern wrote: > Rob Hetland wrote: >> There is also quite a bit of advice on the internet and otherwise >> that 'from numpy import *' is the way to import the library. For >> example, this is the approach in Oliphant's 'Guide to Numpy.' > > You'll often see it in examples because it's the only way to make examples > clear > and to the point. It's not a recommendation.
Indeed. way back when, in the days of Numeric, it WAS the recommendation, then we were in a state of flux, and as Robert said, many quick examples are still written using "import *". However, I have seen a real shift on the numpy list over the last year (or two), toward using the namespace. Paul Kienzle wrote: > On Fri, Jul 20, 2007 at 12:34:44PM -0700, Christopher Barker wrote: >> Out of 491 names in the numpy namespace, I found 26 that would commonly >> be found in math expressions. > The C99 math/complex headers define a number of symbols. Sure, but you don't need all of those. My idea was thus: "Namespaces are one honking great idea" but they are kind of ugly inside math expressions. But: "Practicality beats purity" so I think it does make sense to bring the common names that show up in math expressions into the main namespace. Not all the handy little names ( like isnan, zeros, linspace, etc.) only the ones that show up in the depths of nested math expressions, so that we can write code that looks like math. That's how I came up with my personal list of 26. This is probably best just done by each individual according to his/her taste. Rob Hetland wrote: > I get namespaces. They are really great. It's just that I use numpy > and mpl *so* much that the namespaces get in the way. Maybe using Paul's suggestion of having a "math" namespace that you "import *" would help. Or use "from pylab import *" and reference just the numpy names you want separately. > And really, numpy and mpl coexist beautifully, except for a few small > exceptions. 'load' is one. (There are others I have run across as well). > > I think mpl should play nice even for folks like me who occasionally > like to abandon separate namespaces. But it does. numpy was designed pretty much to do just that -- give you one big namespace to import. And it provides the numerix interface as part of that. However, if you do that, you have to deal with the decisions MPL developers make. numpy is designed by a separate team, and is not designed to be "import *"ed into the pylab namespace (I think it is designed not to clash with the python built-ins at least). This is a common issue with packages developed by different people for similar purposes, and python already has namespaces as a great way to deal with it! Indeed, in this case, I suppose it's the numpy folks that aren't "playing nice" -- numpy.load was added after pylab.load was already there. But it's not a goal of the numpy team to be name-compatible with pylab. -Chris This is really is pretty OT for the devel list, though, so I'll stop here. -- Christopher Barker, Ph.D. Oceanographer 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 [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
