Re: [matplotlib-devel] [Matplotlib-users] check pylab before upcoming release

[Jarrod M. <mi...@be...>]

On Nov 12, 2007 1:19 PM, John Hunter <jd...@gm...> wrote:
> On Nov 12, 2007 12:15 PM, Eric Firing <ef...@ha...> 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/