[IPython-dev] Re: [IPython-user] pysh is in CVS

[Fernando Perez]

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[0]
> 
>  >>> for line in jobs[0].output():
>              if "warning" in line: break
> 
>  >>> jobs[0].change_output(open("/dev/null"),"w")
> 
> # time passes
> 
>  >>> jobs[0].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 :)

Cheers,

f