On Nov 12, 2007 12:15 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > In your list, "load" is duplicated.
Thanks, purged. > On a more strategic note: what do you see as the future of mlab, and its > place in pylab? Should mlab contain every neat function we can think > of, and if so, should all of these be exposed in the pylab namespace? > Do we have or need any quality-control standards for these functions? > Is there a point in exposing more of mlab now than we have in the past? > Probably so, but we might want to be conservative about it. Generally I use cbook as a repository of general purpose helper functions and classes. mlab started life as a repository of matlab compatible functions to supplement those in Numeric's MLab and it has morphed into something a bit looser than that: something like a cbook for stuff with numerical content. Some of the code that started life in mlab has been moved over into numpy (polyfit, polyval, ...) and is now deprecated, some of it serves the plotting functions (cohere, psd, hist, ...), some of it provides a matlab-like function that clashes with a numpy function of the same name (load), some of it is just helper code written primarily by Fernando, me and others that didn't have a better home( eg, Fernando's code lived in ipython for a while and then he contributed it to mlab) One could argue that everything there belongs somewhere else: the load and save and record array loaders and saves belong in scipy.io, the numerical codes belong in scipy or numpy or some sandbox, some of the stuff could just be scrapped as a relic of the past. I don't have a bone to pick with that argument, but I do have a practical concern: I am not a numpy/scipy committer and don't really have the time to become one and it is easier for me to put them into mpl (where I understand the code organization, build process, commit protocol, tests, etc much better) than to go through a numpy or scipy patch development and submission process. I am more than happy for any of this code to end up there and be pulled from mpl. In the past, I've offered this to Travis and he has taken me up on it for some functions, and the same goes for any other user or developer who has strong feelings on how these codes should be organized. Having taught several courses of "scientific computing for python" I am certainly aware of and sympathetic to the complaint that it is difficult to know where to find stuff in the support packages for scientific computing. I am all in favor of getting as much useful stuff into numpy and scipy and organized and documented -- it's just not likely to be me who is the one doing it, just from a time standpoint. So I currently tend to use cbook and mlab as a place for code I develop that is generally useful and is not available in numpy or scipy. Since we are making good progress with cleaning up the namespaces inside mpl and in the examples and in the import layer (eg pyplot), I am happy to *minimize* the contribution of mlab to the pylab namespace. In my scripts I get only "figure", "close" and "show" from pylab anyway so it won't affect me. If we want to stick to the original view of mlab as a repository of matlab-like functions not in scipy or numpy, we can prune the stuff it provides to pylab significantly. I'm also happy to split stuff out of mlab into a different module for clarity if you or others think that would be useful ( I did that originally adding the rec* functions to "recutils", but reverted thinking it would be preferable to add to an existing module than create another one) As for tests and quality control, I'm open to suggestions. For most things, I tend to write an example and add it to the backend driver, which is a test on "still runs" but generally not "runs correctly". Certainly more unit tests would be welcome. JDH ------------------------------------------------------------------------- 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
