Christopher Barker wrote: > Ryan May wrote: >>> I for one will be happy to change my code; numerical stuff in >>> numpy, plotting stuff in pylab (or pyplot?), though some things >>> like linspace() may be hard to loose; that's really an mlab >>> function and I can import mlab. > > I'm a big namespace fan. I'd much rather see us all do something like: > > import pyplot > import numpy as N > import mlab > > etc. > > In this case, there should be little name overlap between these modules, > and you could "import *" all of them if you really wanted. > > However, they are not all maintained by the same folks, so some overlap > may occur, and that's a good reason for keeping them in separate namespaces. > > In any case, it needs to be decided what the point of the mlab module > is. There was a discussion about this a few (quite a few!) years ago > when there was just Numeric, and it came with an mlab module (at least I > think it was called mlab). At that point, we decided that Matlab > compatibility wasn't really the point -- the point was that there were a > number of nifty utilities in Matlab that people missed, and that the > stuff in mlab wasn't completely Matlab compatible anyway (numpy and > Matlab are just plain different, after all). We more or less decided to > what we really needed was a "Utilities" module that could hold some of > those nifty useful functions (like linspace, etc), but not much was done > at the time. Since then, numpy as gained quite a bit of those features > anyway. > > So for this mlab module -- what is the goal? > > 1) A Matlab-like set of tools? In that case, it way want to default to > matrices, rather than arrays, etc. If that's what's wanted, I'd make it > a stand-alone module, that imports what it needs from numpy, but > provides a complete API.
It looks like it started out something like this, but I don't think it should stay that way. If someone wants something like this, I think they will have to do it themselves. > > 2) A bunch of extra utilities that numpy doesn't have, but are handy. In > that case, I'd have it include only the extras, and one would need to > import numpy and mlab both. It could also "import *" numpy , then add > the extra stuff, but I'm too much of a namespace fan to advocate for > that. What happens when numpy adds a name that clashes with an mlab > name, for instance? I think this is the direction mlab has evolved, and my intention is to take it the rest of the way. As with pylab, some degree of matlab-similarity can be retained, but the goal is not a clone--that would be neither attainable nor desirable. If someone wants something more clone-like, they can use octave or scilab. I do not think mlab should "from numpy import *"; if that is what someone wants, they can do it explicitly themselves, very easily. Now, pylab should do something like "from mlab import *; from numpy import *; from pyplot import *", but mlab should be its own nice, clean set of functions. The strategy here is to make a clear distinction between modules that provide unique functionality, and modules that serve as namespace aggregators. Eric > > -Chris > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
