Hi everyone,
sorry for the cross post to those of you who are on all these lists, but since this will affect ipython's future quite a bit, I want a significant heads-up to be seen by all potentially affected.
1. PyGTK & matplotlib
···
---------------------
Thanks to Antoon Pardon and John Hunter, ipython has nearly ready full support for interactive matplotlib with all backends. In this process, we've also added GTK threading support, so you can now use ipython for pygtk development.
This code is now in IPython's CVS, and the matplotlib features require matplotlib CVS (for matplotlib use only; matplotlib has NOT become a general ipython requirement). So those of you willing to bleed a little can use it, and now is your opportunity to let us know of any problems you find.
Our solution is simpler, but more limited in scope, than scipy's gui_thread. However it currently does NOT work with the WX backends, only with Tk and GTK (-AGG or not). Help from any WX guru is welcome, the place to look is at the end of IPython/Shell.py. I hope that we can find, at least in our more limited context, a working solution for WX which doesn't require all the complexity of gui_thread.
In order to use this, do an 'ipython -upgrade' after a cvs update; this will get the necessary support files into ~/.ipython. You will then need to use the new threading options; copying from the docs:
-gthread, -mpthread: these are special options, only one of which can be
given, and which can ONLY be given as the FIRST option passed to IPython
(they will have no effect in any other position).
If -gthread is given, IPython starts running a separate thread for GTK
operation, so that pyGTK-based programs can open GUIs without blocking
IPython.
The -mpthread option adds special support for the matplotlib library
(http://matplotlib.sourceforge.net), allowing interactive usage of the GTK
and WX backends. This also modifies the @run command to correctly execute
any matplotlib-based script which calls show() at the end, without blocking.
The most convenient way to use this is the new pylab profile, which should be invoked as follows (aliasing this in your shell may be a good idea):
$ ipython -mpthread -p pylab
pylab will honor your choice of matplotlib backend, though currently it will revert (with a warning) WX to TkAgg, since WX is broken. This will go away once we figure out the WX problems.
2. IPython's future
-------------------
Once this support for matplotlib is working to satisfaction, it will mean the end of the line for any more feature-related changes to ipython for quite a while. Once this is reasonably shaken (I hope with at most one more release beyond 0.6.3, which will officially include this), I plan on beginning the long-awaited internal cleanup of ipython.
Given my very limited time, this will mean essentially ZERO new features on ipython for quite a while. It will also mean that the new ipython will:
- require python 2.3: I want to deprecate as much redundant code as I can from the ipython distribution. I'll use optparse and any other new module from the stdlib which can help shrink ipython.
- break backwards compatibility in many areas. In particular, the ipythonrc files will become true python files.
- the internal class structure of ipython will drastically change. If you have code which uses ipython via IPython.Shell, you should be fine, as I'll try to keep that API stable. If you've been poking your dirty fingers into iplib or ipmaker directly, expect things to break badly, and don't even think about complaining 
Hopefully once this is over, it will mean having a much cleaner ipython, with an easy path for including it into GUI shells (such as pycrust), and a sane internal code structure. As the new design shakes down, we'll eventually have an ipython 1.0 at last 
Because of these changes coming down the pipe, if you have any further patches or changes for the current ipython which you'd like to see included, please send them NOW to me. Once I shift gears to the cleanup project, I'll unfortunately have to drop most changes not going in that direction, simply for lack of time.
I'd like to thank everybody who has contributed to ipython's development so far, and to encourage others to join in. The cleanup should not be too hard, and it will open the door for having ipython as the interactive core for very high quality python-based environments in the future.
Best regards,
f