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

[Fernando Perez]

Ville Vainio wrote:
> 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 :).

I'll do so when 0.6.1 is out.  I skipped mentioning 0.6.0 b/c it didn't quite 
work for Windows users out-of-the-box.  And I'm not very good at PR :)

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

I've actually included here interactive.py, the multithreaded mini-console 
which ships with matplotlib.  This is what I'll be using as my 'design 
reference', I already spoke to John Hunter (matplotlib's author) and he's OK 
with my blatant ripping code out of there.

Since I know zilch about multithreaded programming, I'd appreciate it if 
anyone sees any fundamental flaws in this code (it's very small) before I 
start really using it.  I am going to try to make a version of ipython (easy 
subclassing) whose inner loop is modeled after this code so that the gtk 
thread can draw without blocking user input/execution.

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

Patches will always be welcome, and I'd actually _like_ the kind of 
functionality you suggest.  It's just that my spare time is very finite.

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

Good catch!  In fact I started using the underlying shell by firing a 
wholesale python interpreter because I simply didn't want to deal with the 
subtleties of parsing a string into a proper sys.argv.  It's an ugly hack, and 
I'd love to get rid of it (plus, it's expensive as you noted).  If anyone can 
provide me with a pure python function which does:

argv_list = parse_string(argv_str)

which takes a string (with arbitrary quotes, parens, etc.) and returns a 
python list which would be the correct sys.argv seen by a command line 
consisting of this argv_str, I'd be very happy.

On this one I punted and decided to let the shell deal with it, but it's 
really an ugly solution.

What I'll do is at least leave this option off by default for most magics, and 
turn it on only for those that _really_ need to be able to reconstruct a 
sys.argv out of a string (basically @run).

This will go into CVS probably tonight.

Cheers,

f

ps.  You might want to subscribe to ipython-dev, I've moved this thread out of 
ipython-users since it's a bit technical for general users.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: interactive.py
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20040628/293f40b8/attachment.ksh>