[IPython-user] pysh is in CVS

[Ville Vainio]

Fernando Perez wrote:

> Seriously, the current pysh functionality is about as far as I can 
> afford to push it myself.  It works great for me,

Fair enough. I imagine other people might want to help too, esp. after 
you do that codebase cleanup you've been talking about so that the 
modifications don't need to be rewritten for the new architecture. And 
you should really post a PR article on c.l.py about the newfound shell 
functionality :).


> 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.

Well, in some toolkits at least all the drawing commands need to be done 
from the same thread (since X is single-threaded).  I imagine you 
weren't trying to execute actual GUI code from the ipython thread?

>   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

As long as you see shell functionality as desirable (and will accept 
patches to implement that), it's all well and good.

>> 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
>
> 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

I could almost swear the delay was because of i/o. Executing normal 
statements was instantaneous even on the slow machine, so I wouldn't be 
so quick to blame the inner loop. I took a look at magic_cd, and the 
call to parse_options catches my eye. Apparently parse_options does lots 
of nasty stuff (like starts another python interpreter in a new shell). 
That's a big hit on slow machines. IMO magic_cd should just do trivial 
option parsing completely in python (current process), shell expansion 
is not really needed .

I changed line 1865 of Magic.py (in cvs) to:
            opts,ps = 
self.parse_options(parameter_s,'q',mode='string',use_shell=False)

i.e. I added use_shell = False. It might break something, but boy, does 
it speed it up on my slow machine.