[SciPy-dev] adding a nice progressbar to scipy

Ondrej Certik ondrej@certik...
Thu Jan 10 13:32:52 CST 2008


On Jan 10, 2008 8:08 PM, Fernando Perez <fperez.net@gmail.com> wrote:
> On Jan 10, 2008 10:06 AM, Ondrej Certik <ondrej@certik.cz> 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
> double-packaging.
>
> 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
includes stuff
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
in python.

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.



Ondrej


More information about the Scipy-dev mailing list