John, Thanks for the clarification---and for responding so close to the holiday! > It seems like matplotlib should track released scipy rather than scipy > svn, but I can see arguments for both sides (matplotlib cvs perhaps > should track scipy svn, but then we can't do a release until scipy > does...). I understand the issue, and it does seem to me you should track the release. > I know there has been some recent discussion and work on the scipy dev > list about a new package loading scheme, but am not sure what the > current status is (still in flux, finished). At least part of it was given up on, and I believe Pearu and Travis checked in those changes a few days ago. It does sound like it's time for a new release, provided the scheme has settled. For others trying to use things as they are now, the following quick fix gets most things to work: Just change __init__.py in site-packages/matplotlib/numerix/fft from: elif which[0] == "scipy": from scipy.basic.fft import * to: elif which[0] == "scipy": # from scipy.basic.fft import * from scipy.basic.fftpack import * Do it in site-packages and not in the distribution, so your distribution stays in sync with its CVS version. (I'm not sure if this matters.) I don't know if this does all that is required for pylab's fft stuff (I only use it for plotting), but it does get *most* examples to plot (I tried a random assortment of them). However, a few examples do have problems, some trivial, others perhaps not so. Some examples: % pythonw specgram_demo.py Traceback (most recent call last): File "specgram_demo.py", line 24, in ? Pxx, freqs, bins, im = specgram(x, NFFT=NFFT, Fs=Fs, noverlap=900) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/pylab.py", line 2206, in specgram ret = gca().specgram(*args, **kwargs) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/axes.py", line 3379, in specgram window, noverlap) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/mlab.py", line 1120, in specgram if x.typecode()==Complex: numFreqs = NFFT AttributeError: 'scipy.ndarray' object has no attribute 'typecode' scipy_core has changed how typecodes are handled so I suspect this is an inconsistency that will survive revisions. I don't know what else in mpl it may affect. % pythonw boxplot_demo.py Traceback (most recent call last): File "boxplot_demo.py", line 17, in ? boxplot(data) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/pylab.py", line 1745, in boxplot ret = gca().boxplot(*args, **kwargs) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/axes.py", line 1061, in boxplot widths = distance * min(0.15, 0.5/distance) ZeroDivisionError: float division I don't know what's behind this. % pythonw anim.py The animated plot appears to work fine---what I could see of it! Its window can't be brought to the front, and won't respond to clicks on the close button. I believe this has always happened and is unrelated to scipy; it's an OS X GUI issue (I'm using TkAgg). %pythonw dannys_example.py This failed for me because it is written to explicitly use Numeric. A simple change at the top to "import matplotlib.numerix as Numeric" has it plot fine with scipy. Someone should check it with numarray and if it survives, make the change. Many other examples worked just fine, with images, contour plots, histograms, TeX labels, axis tricks, interactivity, etc.. So perhaps the only scipy_core changes that are significant for mpl are the fft module move and the typecode change. -Tom ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/