[IPython-dev] Python-based configuration system

Fernando Perez Fernando.Perez at colorado.edu
Wed Jun 30 10:26:11 CDT 2004


Ville Vainio wrote:
> Apparently replacing the current configuration system with a 
> python-based one should not be too much work:

[snip]

The work isn't hard, it's just a matter of going through the hairball of the 
current code and ripping out all the deadwood.  The issue is just one of time, 
not of difficulty.  Nothing in ipython is actually difficult code by any 
stretch of the imagination, it's just a bunch of useful simple things strung 
together.  Something along the lines of what you suggest is pretty much what I 
had in mind.

If you want to actually get going with this kind of work, I'm happy to have a 
helping hand.  We can even set up a dev CVS branch for these changes, so that 
we can play safely with the code without breaking the mainline.

But I need to do a few things in order:

1. Get 0.6.1 out officially.  We can include your @bookmarks patches if you 
want.  This could be done relatively soon, since most issues seem more or less 
resolved.  The only ones I can see left are:

  a. http://www.scipy.net/roundup/ipython/issue6
  b. Cygwin readline problems.  I don't know what to do here, it will probably
     stay as it is.
  c. The windows GUI installer.  Viktor, do you have a feel for whether you
     think you can make it work for 0.6.1?

2. Write a multithreaded version of ipython like the interactive.py from 
matplotlib I recently posted.  Sorry about this, but I won't move forward 
until I can do this, since: a) I promised it already to others b) I also need 
it for my own work.

If you think you can/want to pitch in with 2, that would be _great_.  If not, 
and you don't want my working on that to hold you back, we can set up a CVS 
dev branch after 1. is done so you can start playing with it while I write the 
multithreaded code.  The danger of doing this is that we may break sync:  I 
may need to refactor ipython's read/eval loop a bit for threads.  So I'd 
rather do this in order with you.

3. By the time we put out 0.6.2 with the multithreaded ipython included, we'll 
flush out any bug reports which may have come from 0.6.1, esp. about pysh. 
This can then be considered 'end of the road' for the current codebase.

At this point we can start really tearing the code, chainsaw in hand.

How does that sound?

Cheers,

f




More information about the IPython-dev mailing list