This is a great project and I’m sure we’re all looking forward to having “just one way to do it”.
However, do not overestimate how up-to-date these packages will be, particularly in managed environments. For instance the RHEL4 boxes we run at my employer still have pygtk 2.4. (Yes, that is 4 years old!) It would be unfortunate if our users couldn’t update matplotlib without the pain of recompiling a large part of the gtk stack underneath.
I am fully aware that some environments upgrade things like GUI toolkits over very long time scales. More important - there isn’t a released version of wx that has these capabilities in it. It will be a long time before everyone is running the needed versions of wx/gtk/qt. In the meantime, we will do everything we can to make sure that people running older versions of GUI toolkits can continue to use IPython (and mpl).
On the mpl side of things, there will probably have to be some changes to the GUI toolkit initialization code that detects which way things are being run (old/new) and then does the right thing. If we coordinate this well, that should allow newer versions of mpl to work with both new and old versions of IPython and the GUI toolkits. However at some point, we will have to make a clean break.
So just a plea to keep the old code paths working – perhaps surrounded in big flashing “REMOVE ME LATER” comments. I understand that maintaining code that fewer and fewer users will be running is like a time bomb.
This is especially true of the threaded Shells in IPython. Honestly, even with thousands of people using it (as is currently the case) it is a time bomb.
Maybe we could raise a deprecation warning if a user has an old version of a toolkit, so at least when the bomb finally goes off the user has a first guess as to why. But I think dropping all support for these older versions in one step would be a mistake.
Yes, there will definitely have to be some sort of transition. One possibility is that during the transition, the old threaded Shells would slowly loose features that become impossible to maintain (such as interrupt handling in the threaded shells).
With our very limited IPython manpower, we have a very fine line to walk between moving forward and maintaining backwards compatibility.
Brian Granger wrote:
[sent to mpl-dev, enthought-dev and ipython-dev]
This summer, we are doing some major refactoring of IPython’s core. One of the things I am working on is changing how IPython’s works with GUI toolkits. These changes will have a significant impact (hopefully for the better) on your project, so I wanted to open a discussion about this issue.
Here is the current situation: currently, IPython uses threads to allow GUI event loops. This code lives in IPython.Shell and is extremely subtle, hard to maintain and fragile. Fernando and John Hunter have done a fantastic job in developing this code, but in the long run we need a more robust approach.
Here is the proposal: Python has an obscure hook called PyOS_InputHook. By using this hook, GUI toolkits can interleave their event loop with a command line program without threads. Even though PyOS_InputHook is not well known, this is how Python’s built-in integration with Tk works. The good news is that other GUI toolkits are starting to support PyOS_InputHook:
PyGTK 2.15.1 has this.
The mpl MacOSX backend works this way
Recent versions of PyQT 4 have this.
I am working with Robin Dunn to implement this in wxPython 2.8 and 2.9
Bottom line: once people are using these recent/upcoming versions of the GUI toolkits, IPython will no longer need to maintain the code in Shell.py and IPython won’t need to have -pylab/-wthread/etc options.
So, how does affect your project?
People will be able to use your project interactive from the regular python prompt.
You will need to make small changes to your GUI toolkits initialization code.
All of us will need to coordinate version transitions to make sure that there is a clean transition to this new approach.
I need help testing the new approach (especially with wxPython) to make sure that your project actually works with the new approach.
What needs to be done at this point?
I would like to discuss how the transition should be made in terms of versions.
I need help testing this new approach in the various toolkits - especially with wx.
I want to see if there are other issues related to this that I am missing.
Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World™ will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge
Matplotlib-devel mailing list
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA