[SciPy-dev] adding a nice progressbar to scipy
Thu Jan 10 13:32:52 CST 2008
On Jan 10, 2008 8:08 PM, Fernando Perez <firstname.lastname@example.org> wrote:
> On Jan 10, 2008 10:06 AM, Ondrej Certik <email@example.com> wrote:
> > > > Especially the ETA is very handy, because I get a clue how long I need
> > > > to wait for my code
> > > > to finish and I get it for free (see the above example).
> > > >
> > > I tend to think that something like this might be more useful for
> > > IPython, or some other interactive environment. But, I'm open to
> > > opinions.
> > Yes, or ipython. All I want is that it is part of some standard
> > package, so that it's installed by default.
> Well, here we're back to the old discussion between 'integrated,
> all-encompassing packages' and modular libraries.
> The progressbar package is already in pypi, so anyone can install it with
> easy_install progressbar
> So the question is, what do we win by bundling it. Mostly convenience
> for end users. But then that means we have to put it somewhere.
> Where? Do we simply swallow it into ipython? I'm not sure the
> original developer would want that. Do we put it into
> ipython.externals (we have that for external packages we absolutely
> need). That's certainly a possibility, but then slowly ipython will
> begin to carry other third-party projects we need to sync with, etc.
> And at some point, that becomes the problem Sage already faces: you
> duplicate lots of stuff, and distributors (like Debian) start to
> complain that it doesn't make sense to have this type of
> In the scipy world, we've taken an approach in many ways opposite to
> sage: well-defined and separated tools that do one thing well each
> (ipython, numpy, scipy, matplotlib, etc). People are then free to
> assemble them as they best see fit. This has both pluses and minuses.
> Sage has gone the other way: include the entire universe inside, down
> to python itself, a Fortran compiler, low-level system libraries like
> termcap, etc. Sage is almost an operating system (in fact for windows
> it is, since Sage for windows ships an entire Linux distribution as a
> VMWare image). There's an undeniable advantage of convenience for end
> users here, but it also does cause problems on other fronts.
> Asking for progressbar *inside* ipython is asking for that kind of
> 'bundle everything that could be useful' approach.
> How do you see that balance? What's the perspective of others? I
> have a lot more thoughts on this question, and in fact it's something
> I hope to discuss in detail at the Sage/Scipy meeting, but I'd like to
> hear other opinions.
I think such a question cannot be "objectively decided". It's just a matter
of personal preferences and a consensus among scipy/numpy/etc
developers and users.
I agree that this double or triple packaging sucks. But scipy also
like superlu and umfpack, that you can simply ask users to install. I
think the scipy
package should include tools, that people use frequently when dealing
with scientific calculations
So it boils down to a question - do you find the progressbar as useful
as I do and would you
use it in your projects? Would you use it in your projects when
(mostly) working with scipy or ipython?
If the answer to both is yes, then I think it could be included (as it
is small). If it's only me,
then I think it shouldn't be included.
More information about the Scipy-dev