[IPython-dev] Re: [IPython-user] pysh is in CVS
Fernando.Perez at colorado.edu
Mon Jun 28 15:18:18 CDT 2004
Ville Vainio wrote:
>>Don't even ask for job control, builtin piping, etc.
> Don't dismiss job control so quickly ;-).
> ipython might even be useful for doing much more "advanced" job control
> that what you typically do with bash:
> >>> !& tail -f output.log
> # launched job, "job object" is in jobs
> >>> for line in jobs.output():
> if "warning" in line: break
> >>> jobs.change_output(open("/dev/null"),"w")
> # time passes
> >>> jobs.interact() # output comes back to current terminal
Nifty idea indeed. You may have to roll up your sleeves after all, heh? ;-)
Seriously, the current pysh functionality is about as far as I can afford to
push it myself. It works great for me, and I'm already enjoying easy looping
with real python syntax for things with my filesystem. Plus a shell which is
itself a calculator is always handy. I'll polish things a bit, fix problems
as they appear, but that's about it.
My next item is a multithreaded ipython so I can use matplotlib interactively
with a GTK frontend. This will allow anyone to run GTK/Wx apps from within
ipython without the GUI loop blocking ipython itself. I had a stab at it
Saturday evening but I failed, I'll try again over the next few weeks. Since
I've never written a line of multithreaded code, it will take me a bit of
effort I'm sure.
After I finish the multithreaded ipython, so that a pylab profile can be
shipped for a matlab-like environment (using matplotlib), I'll begin the slow
cleanup of the internals. This will set the stage for inclusion of ipython
into IDLE, PyCrust, etc. I already did a quick test and I can sort of run
ipython inside IDLE, so it's definitely doable. It will just take some time.
This is necessary for the kind of scientific computing environment (or coding
in general, it's just that sci-comp is my field) that I envision and which we
discussed a while back with Ero's Texmacs example. Since that's the direction
_I_ will be pushing things in, fancy shell functionality will have to be done
by others. I already broke my own promise of not writing pysh once, I won't
do it twice :)
> Yup, pysh seemed to work alright. One thing that is still noticeably
> slower than on bash is changing the directory with "cd" - on a slow
> machine you have enough time to type "ls" and blink an eye before
> ipython shows the prompt again. On a faster machine it's ok, obviously.
> This is true for both "pysh" and plain unconfigured ipython.
I'm afraid there's not much I can do here. All the niceties of ipython come
at a price: the inner loop is a very complicated piece of code, with string
analysis, regexp checks, multiple try/excepts, etc. None of this is
expendable, if you really want all the magic behavior which makes ipython so
nice. If you want a fast inner loop, implementing plain python behavior is
trivial (see code.py in the stdlib). As always, there's no free lunch.
It may be possible to optimize things a bit, but I doubt major improvements
are possible. Feel free to prove me wrong though :) Keep in mind that this
code is often very subtle, and almost any change will break some corner case,
so be careful before cutting out any seemingly 'dumb' codepath; chances are
it's there for a very good reason. The code is also hackish, dirty and
uncommented. Oh, and there are no unit tests for it. Have fun :)
More information about the IPython-dev