[IPython-dev] ipython, gtk & matplotlib support; end of current ipython development

Fernando Perez Fernando.Perez at colorado.edu
Sun Aug 22 18:56:38 EDT 2004

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

  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,


More information about the IPython-dev mailing list