[IPython-dev] Adding a nice progressbar to scipy

[Fernando Perez]

[ Note: this is continued from scipy-dev:
http://projects.scipy.org/pipermail/scipy-dev/2008-January/008200.html

The code in question is:
http://pypi.python.org/pypi/progressbar

I'm moving the discussion here b/c now it's an ipython thing. ]

On Jan 11, 2008 7:54 PM, Ondrej Certik <ondrej at certik.cz> wrote:
> On Jan 12, 2008 3:26 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> >
> > On Jan 11, 2008 6:52 PM, Ondrej Certik <ondrej at certik.cz> wrote:
> > > So what is the conclusion?
> > >
> > > Maybe I should stress, that the progress bar is just one file with 300
> > > lines of code.
> > >
> > > So it's not really a package, just a feature. I was thinking of
> > > scipy.io, but ipython
> > > is maybe better. If it can contain interaction with gnuplot, why not a simple
> > > progressbar? :)

BTW, the gnuplot and numeric support are old and deprecated, code from
2001 when Numeric was much more limited than numpy and matplotlib
didn't exist :)  We've precisely moved into a world where we try to
have better defined responsibilities (scipy used to have plotting and
that got taken out, matplotlib used to have a shell and that got taken
out, etc.).  Having said that, an interactive progress bar *does* make
sense for ipython, which is why I'm willing to entertain this
discussion.

> > A few questions:
> >
> > - Will it run *correctly* under Windows?  I don't use it, but I don't
> > want the text-only core of ipython to start sprouting functionality
> > that breaks under windows (or any OS for that matter).  Same thing for
> > Linux/OSX.  I know it says 'os independent', but I want independent
> > confirmation of that statement.
>
> Right, I don't know, since I don't use windows and I cannot test it.

I don't want to sound harsh, but since you're the one asking for the
feature, you'll have to do a bit of the work.  Either a windows user
from the list can help you out with testing it, or you can borrow a
friend's windows computer for 20 minutes for testing it.

I'm sorry to say this, but even as much as I dislike windows myself
for personal use, we do our best with ipython to be good windows
citizens. Ville and Jorgen have put a LOT of work into making ipython
behave well for windows, and I'm not about to throw on their lap a
feature  that could cause them grief, especially since they didn't
even ask for it in the first place.

So if you want it, you'll need to first satisfy these concerns and
find a way to get it checked.  Now, it looks like it's doable, so over
a few days I'm sure you can find a way to get the code checked out and
cleaned up; if it makes your life easier we can drop it in for SVN and
you can work on the cleanup. We recently had a WX ipython committed
that had cross-platform issues, and the developer has been gradually
working on them.

So I'm not asking you for perfect code out of the box, but I can't
drop code in that may have cross-platform problems if you don't commit
to fixing them if they arise.

> > - It makes calls to ioctl() without checks that the import at the top
> > actually worked.  That will break somewhere, I guarantee it.
>
> It's used in handle_resize only, which is only used in
>
>             try:
>                 self.handle_resize(None,None)
>                 signal.signal(signal.SIGWINCH, self.handle_resize)
>                 self.signal_set = True
>             except:
>                 self.term_width = 79
>
> I am not saying it's the best programming practice, but I think
> it will work without ioctl quite well.
>
> > - Is signal.SIGWINCH available on all OSes?
>
> I don't know.
>
> > - termios is also used without checks.  That will likely throw an
> > exception under windows.
>
> Again only in handle_resize(), which is only called in the code above,
> so it should be safe.
>
> > - Etc.  This code doesn't look like it's ever been properly tested for
> > cross-platform compatibility.  Welcome to the real world.
>
> Right. I can only say that it works well in Debian.
>
> > If all of the above were to be addressed, it's small enough that I'm
> > willing to throw it into ipython.externals for convenience.  300 lines
> > is a drop in the bucket at this point, and for interactive work it can
> > come in very handy, I agree.  No sysadmin will notice it's hiding in
> > there :)
> >
> > In this case, a few things:
> >
> > - You said that the author would BSD license it, but the current code
> > http://pypi.python.org/pypi/progressbar still shows LGPL-only.  I
> > won't put it in until we get from him a BSD-licensed file.
>
> Yes, he only sent an email to me, I can ask him to send an email to
> this list too.
>
> > - Please send us the patch you suggested writing for the more comon case.
>
> I'll send it to the ipython list.
>
> > - You commit to letting us know when an update is warranted and
> > sending us the corresponding patch, so that the ipython developers can
> > apply it with minimal effort.
>
> I commit. The final decision needs to be made by ipython developers though,
> if they are willing to maintain such a code if I won't be available
> (for any reason). But except
> the points you raised, I think it's very readable, so there shouldn't
> be a problem with that.

I hope the above is clear enough.  If one of our core windows people
finds this code useful and is willing to help Ondrej test that part
and clean it up, that would be great.  I think this feature can be
useful, but I'm just making sure that Ville and Jorgen don't end up
with a problem on their hands they didn't bargain for.

Cheers,

f