matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
> 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). Robert or Travis, please
> advise about the status of this module, and when you expect a scipy
> release which has the new package loading scheme out.
I think we'll be going through one more iteration, but I won't be able to attend
to it until Jan 3. If we follow my plan, then you would do
 from scipy.corefft import *
No weird import tricks are involved.
-- 
Robert Kern
rob...@gm...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

> In [4]: import scipy.fftpack
> ------------------------------------------------------------
> Traceback (most recent call last):
> File "<console>", line 1, in ?
> ImportError: No module named fftpack
> 
> Although scipy.fftpack is defined in 0.8.4, you can't import from it
> like a normal module.
Yes, this has been the subject of attention in the last week
(see e.g. the scipy-dev threads on the location of the random
module, and on "fftpack issues"). They decided to abandon
some of the delayed import magic, and the current SVN checkout
reflects this. You can now import fftpack as before. I 
suspect there will be a new release soon after the holiday
reflecting this fix. Even after such a release, there will
be a problem with folks updating mpl without also updating
scipy_core. So I suspect either you'll have to find a more
clever way of importing ffts that maintains compatibility
across recent inconsistent scipy_core releases, or you'll
have to require mpl users to update scipy_core. A bit of
a mess....
-Tom

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 >> 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 *
 >> 
 Eric> John,
 Eric> It looks like this could be handled in CVS mpl with:
 Eric> elif which[0] == "scipy": from scipy.fftpack import *
 Eric> scipy itself imports basic.fft (released version) or
 Eric> basic.fftpack (SVN) as fftpack, so there is no need to go to
 Eric> scipy.basic. Correct?
 Eric> I haven't tested it yet, though. If no one gets to it
 Eric> sooner, I may be able to take a closer look this evening.
I don't think this works with the latest release
In [2]: import scipy
In [3]: scipy.__core_version__
Out[3]: '0.8.4'
In [4]: import scipy.fftpack
------------------------------------------------------------
Traceback (most recent call last):
 File "<console>", line 1, in ?
ImportError: No module named fftpack
Although scipy.fftpack is defined in 0.8.4, you can't import from it
like a normal module.
JDH

> 
> 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 *
> 
John,
It looks like this could be handled in CVS mpl with:
elif which[0] == "scipy":
 from scipy.fftpack import *
scipy itself imports basic.fft (released version) or basic.fftpack (SVN) 
as fftpack, so there is no need to go to scipy.basic. Correct?
I haven't tested it yet, though. If no one gets to it sooner, I may be 
able to take a closer look this evening.
Eric

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/

>>>>> "Tom" == Tom Loredo <lo...@as...> writes:
 Tom> Hi folks,
 Tom> I just installed the latest svn/cvs scipy_core, scipy, and
 Tom> mpl on OS 10.3.9, Py 2.4.1. There has been some shuffling
 Tom> around of packages and package names in scipy in the last
 Tom> week or two, and finally core+scipy is working without import
 Tom> complaints (though 10 of the fftpack tests fail). However,
 Tom> now NOTHING requiring pylab works---every attempt to import
 Tom> pylab eventually fails with something like:
 Tom> File
 Tom> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/numerix/
 Tom> __init__.py", line 143, in ? __import__('fft', g, l) File
 Tom> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/numerix/fft/
 Tom> __init__.py", line 8, in ? from scipy.basic.fft import *
 Tom> ImportError: No module named fft
That is a bit of a problem, since this is correct with the last
released version of scipy
In [1]: import scipy
In [2]: scipy.__core_version__
Out[2]: '0.8.4'
In [3]: from scipy.basic.fft import *
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 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). Robert or Travis, please
advise about the status of this module, and when you expect a scipy
release which has the new package loading scheme out.
JDH

Hi folks,
I just installed the latest svn/cvs scipy_core, scipy, and mpl
on OS 10.3.9, Py 2.4.1. There has been some shuffling around
of packages and package names in scipy in the last week or two,
and finally core+scipy is working without import complaints
(though 10 of the fftpack tests fail). However, now NOTHING
requiring pylab works---every attempt to import pylab eventually
fails with something like:
 File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/numerix/
__init__.py", line 143, in ?
 __import__('fft', g, l)
 File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/numerix/fft/
__init__.py", line 8, in ?
 from scipy.basic.fft import *
ImportError: No module named fft
Indeed, checking scipy verifies that scipy.basic.fft is now a 
*function* (ifft also); the module is fftpack (or fftpack_lite),
not fft:
>>> import scipy
>>> dir(scipy.basic)
['ScipyTest', '__builtins__', '__doc__', '__file__', '__name__', '__path__', 'fft', 'fftpack', 'fftpack_lite', 
'helper', 'ifft', 'lapack_lite', 'linalg', 'rand', 'randn', 'random', 'test']
>>> scipy.basic.fft
<function fft at 0x515470> 
I don't know who has to sort this out, scipy or mpl developers,
but I sure hope it can be done soon!
Thanks,
Tom
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/