On Nov 12, 2007 1:19 PM, John Hunter <[EMAIL PROTECTED]> wrote: > On Nov 12, 2007 12:15 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > > 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. > > 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.
Hey John, I am willing to commit to helping migrating the relevant mlab code over to SciPy (or NumPy). The next release of SciPy (http://projects.scipy.org/scipy/scipy/milestone/0.7) may be pushed back a little, but it should be out by February at the latest. One of the things I had been planning to work on for this release was going over the various scipy.io code anyway. I probably won't get a chance to take a close look at things until December, but I thought I would mention it in case it has any impact on your own plans. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ------------------------------------------------------------------------- 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
