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