matplotlib-users Mailing List for matplotlib

One more thing: knowing Chris, I *think* that he wasn't saying that you 
should somehow *oblige* the coder to use namespace prefices, rather, 
don't do anything that would make it harder or less efficient to do so, 
right Chris?
DG
Christopher Barker wrote:
> Keir Mierle wrote:
> 
>> p.s. This is part of my plan to kick off http://scipy.org/PyLab
>> 
>
> Great Plan, and I think kicking it off with better docstrings is a good 
> start.
>
> One comment, from your Wiki Page:
>
> """
> I feel strongly that the correct way to import the entire core PyLab API 
> should be via
>
> from pylab import *
> """
>
> No, no, no, no NO!
>
> see, I feel strongly too ;-).
>
> You are trying to build something that is better than MATLAB. The one 
> way you are almost guaranteed to achieve that is that it is built on the 
> Python language, which is much more powerful and flexible than Matlab, 
> but you know that already.
>
> However, you are tossing away a lot of the advantage if you don't keep 
> the focus on being pythonic, and that means, in this case:
>
> "Namespaces are one honking great idea -- let's do more of those!"
>
> note, NOT "fewer of those"
>
> numpy + matplotlib + scipy
>
> is a LOT of functionality. It should not be all in the same namespace. 
> It's really not that hard to do something like:
>
> import matplotlib as plot
> import numpy as N
> import Scipy.whatever as whatever.
>
> I think it's very helpful to keep things clean and separated. Sure, you 
> can work to remove duplication an name clashes among these three 
> packages, but what if the user decides they also need PIL, or PyGame, or 
> PyNetCDF, etc, etc. One of the real powers of Python is that it has 
> broad use, and that there is a module for just about everything you need 
> to do, all maintained by others -- you are guaranteed name clashes if 
> you don't use namespaces -- that's what they are for.
>
> Note python itself. A lot of common functionality is in modules you need 
> to import: sys, os, sys.path, string (though string methods remove much 
> of that need) This is a GOOD model!
>
> Also, I'd really like to see far more use of an OO approach in 
> matplotlib use (and maybe scipy -- I haven't used much of it). If you 
> note, numpy has made lots of things ndarray methods that were functions 
> in Numeric -- this makes NOT using "import *" much cleaner.
>
> In short: I think your goals are great, most of your approach is good, 
> but please: Keep PyLab pythonic -- don't try to make it more like 
> matlab, or fortran, or any other language -- your users will thank you 
> for it later!
>
> See recent discussions on the matplotlib list about this topic. I think 
> even John is shifting toward wanting more use of the OO interface.
>
> -Chris
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 
-- 
ERD/ORR/NOS/NOAA <http://response.restoration.noaa.gov/emergencyresponse/>

One more namespace "pro" (on point, since you're concerned w/ 
docstrings, and thus, presumably, usability): indicating the namespace 
makes your code more self-documenting (my favorite aspect of it).
DG
Christopher Barker wrote:
> Keir Mierle wrote:
> 
>> p.s. This is part of my plan to kick off http://scipy.org/PyLab
>> 
>
> Great Plan, and I think kicking it off with better docstrings is a good 
> start.
>
> One comment, from your Wiki Page:
>
> """
> I feel strongly that the correct way to import the entire core PyLab API 
> should be via
>
> from pylab import *
> """
>
> No, no, no, no NO!
>
> see, I feel strongly too ;-).
>
> You are trying to build something that is better than MATLAB. The one 
> way you are almost guaranteed to achieve that is that it is built on the 
> Python language, which is much more powerful and flexible than Matlab, 
> but you know that already.
>
> However, you are tossing away a lot of the advantage if you don't keep 
> the focus on being pythonic, and that means, in this case:
>
> "Namespaces are one honking great idea -- let's do more of those!"
>
> note, NOT "fewer of those"
>
> numpy + matplotlib + scipy
>
> is a LOT of functionality. It should not be all in the same namespace. 
> It's really not that hard to do something like:
>
> import matplotlib as plot
> import numpy as N
> import Scipy.whatever as whatever.
>
> I think it's very helpful to keep things clean and separated. Sure, you 
> can work to remove duplication an name clashes among these three 
> packages, but what if the user decides they also need PIL, or PyGame, or 
> PyNetCDF, etc, etc. One of the real powers of Python is that it has 
> broad use, and that there is a module for just about everything you need 
> to do, all maintained by others -- you are guaranteed name clashes if 
> you don't use namespaces -- that's what they are for.
>
> Note python itself. A lot of common functionality is in modules you need 
> to import: sys, os, sys.path, string (though string methods remove much 
> of that need) This is a GOOD model!
>
> Also, I'd really like to see far more use of an OO approach in 
> matplotlib use (and maybe scipy -- I haven't used much of it). If you 
> note, numpy has made lots of things ndarray methods that were functions 
> in Numeric -- this makes NOT using "import *" much cleaner.
>
> In short: I think your goals are great, most of your approach is good, 
> but please: Keep PyLab pythonic -- don't try to make it more like 
> matlab, or fortran, or any other language -- your users will thank you 
> for it later!
>
> See recent discussions on the matplotlib list about this topic. I think 
> even John is shifting toward wanting more use of the OO interface.
>
> -Chris
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 
-- 
ERD/ORR/NOS/NOAA <http://response.restoration.noaa.gov/emergencyresponse/>

Keir Mierle wrote:
> p.s. This is part of my plan to kick off http://scipy.org/PyLab
Great Plan, and I think kicking it off with better docstrings is a good 
start.
One comment, from your Wiki Page:
"""
I feel strongly that the correct way to import the entire core PyLab API 
should be via
from pylab import *
"""
No, no, no, no NO!
see, I feel strongly too ;-).
You are trying to build something that is better than MATLAB. The one 
way you are almost guaranteed to achieve that is that it is built on the 
Python language, which is much more powerful and flexible than Matlab, 
but you know that already.
However, you are tossing away a lot of the advantage if you don't keep 
the focus on being pythonic, and that means, in this case:
"Namespaces are one honking great idea -- let's do more of those!"
note, NOT "fewer of those"
numpy + matplotlib + scipy
is a LOT of functionality. It should not be all in the same namespace. 
It's really not that hard to do something like:
import matplotlib as plot
import numpy as N
import Scipy.whatever as whatever.
I think it's very helpful to keep things clean and separated. Sure, you 
can work to remove duplication an name clashes among these three 
packages, but what if the user decides they also need PIL, or PyGame, or 
PyNetCDF, etc, etc. One of the real powers of Python is that it has 
broad use, and that there is a module for just about everything you need 
to do, all maintained by others -- you are guaranteed name clashes if 
you don't use namespaces -- that's what they are for.
Note python itself. A lot of common functionality is in modules you need 
to import: sys, os, sys.path, string (though string methods remove much 
of that need) This is a GOOD model!
Also, I'd really like to see far more use of an OO approach in 
matplotlib use (and maybe scipy -- I haven't used much of it). If you 
note, numpy has made lots of things ndarray methods that were functions 
in Numeric -- this makes NOT using "import *" much cleaner.
In short: I think your goals are great, most of your approach is good, 
but please: Keep PyLab pythonic -- don't try to make it more like 
matlab, or fortran, or any other language -- your users will thank you 
for it later!
See recent discussions on the matplotlib list about this topic. I think 
even John is shifting toward wanting more use of the OO interface.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

How do I make a second x-axis? I am looking for something like "twinx" (a
"twiny" would be perfect...)
Thanks, Evan

Mark Bakker wrote:
> Eric -
> 
> Thanks for your reply.
> Let me give you my idea about axis('scaled') and why I am asking for a 
> change (a new option would be fine as well).
OK, your explanation of the use case is very helpful. I am thinking 
that the problem here is that we are trying to get the axis() function 
to do too many different things--as a Matlab legacy it is already doing 
quite a variety of things, and the more we load in the worse it gets.
It may be that the clean solution for your use case is to simply make a 
direct pylab interface to axes.set_aspect(), because I think that this 
is what really matches your use case. Doing so would be easy, and quite 
consistent with the pylab interface in general. A slightly different 
approach would be to make a pylab function data_aspect() that would call 
gca().set_aspect() with adjustable=box (at least by default). The 
reason for suggesting this is that the name "set_aspect" does not make 
it clear whether we are talking about data coordinates or display 
coordinates.
This may take a little more thought and fiddling, but in any case I am 
pretty sure that continuing to pile things into the 
bursting-at-the-seams axis() function is not a good idea.
Eric

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John Hunter wrote:
| On 2/15/07, David D Clark <dd...@la...> wrote:
|
|> Thanks for the reply. I thought it might have to do with that. I am a
|> new python/matplotlib user. In my inexperience, I'm not sure what I
|> should use for "o" in o.set_visible
|
| o in the example above is any matplotlib artist, eg a line (returned
| by plot), a text instance (returned by set_xlabel, set_ylabel,
| set_title), a rectangle (returned by bar), etc.. Perhaps the example
| below will clarify
|
|
| Example Removed
John,
That did the trick! I'm in business!
Dave
- --
David D. Clark
Electrical Engineer
P-23, Neutron Science and Technology
ph. 505.667.4147 fx. 505.665.4121 pg. 505.996.1416
e-mail mailto:dd...@la...
GPG Public key 0x018D6523 available at http://www.us.pgp.net
http://www.gnupg.org has information about public key cryptography
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF1KgsNu7GcwGNZSMRAjmxAKCUukibHuMkDiOoDK9H/AmmzmTVjACfe3p2
UmxtdeT6Oil6hvWopz7znjk=
=JshG
-----END PGP SIGNATURE-----

On 2/15/07, David D Clark <dd...@la...> wrote:
> Thanks for the reply. I thought it might have to do with that. I am a
> new python/matplotlib user. In my inexperience, I'm not sure what I
> should use for "o" in o.set_visible
o in the example above is any matplotlib artist, eg a line (returned
by plot), a text instance (returned by set_xlabel, set_ylabel,
set_title), a rectangle (returned by bar), etc.. Perhaps the example
below will clarify
In [1]: fig = figure()
In [2]: ax = fig.add_subplot(111)
In [3]: line, = ax.plot([1,2,3])
In [4]: xl = ax.set_xlabel('time')
In [5]: yl = ax.set_ylabel('volts')
In [7]: bars = ax.bar([1,2,3], rand(3))
In [8]: xl
Out[8]: <matplotlib.text.Text instance at 0x3c37238>
In [9]: yl
Out[9]: <matplotlib.text.Text instance at 0x3c37df0>
In [10]: line
Out[10]: <matplotlib.lines.Line2D instance at 0x3c3e558>
In [11]: bars
Out[11]:
[<matplotlib.patches.Rectangle instance at 0x6c92bc0>,
 <matplotlib.patches.Rectangle instance at 0x6c92be8>,
 <matplotlib.patches.Rectangle instance at 0x6c92c60>]
In [12]: xl.set_visible(False)
In [13]: draw()
In [14]: bars[1].set_visible(False)
In [15]: draw()

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John Hunter wrote:
| On 2/14/07, David Clark (Lists) <dd...@la...> wrote:
|
|> I'm working on a GUI with wxPython to display several traces of data.
|> Using a checkbox, I would like to be able to turn traces on the plot on
|> and off. I have managed to find the right methods to turn the whole
|> axes on and off, but not individual traces. Any help would be
|> appreciated.
|
|
| Everythong that draws into a figure (Axes, Text, Line2D, Polygon,
| etc...) all derive from Artist which has a visible property. So you
| can turn anything off/on with
|
| o.set_visible(True|False)
|
| JDH
John,
Thanks for the reply. I thought it might have to do with that. I am a
new python/matplotlib user. In my inexperience, I'm not sure what I
should use for "o" in o.set_visible
Thanks,
Dave
- --
David D. Clark
Electrical Engineer
P-23, Neutron Science and Technology
ph. 505.667.4147 fx. 505.665.4121 pg. 505.996.1416
e-mail mailto:dd...@la...
GPG Public key 0x018D6523 available at http://www.us.pgp.net
http://www.gnupg.org has information about public key cryptography
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF1J7gNu7GcwGNZSMRAm17AJ4gOygLy1aw75NaVtPq8jQ1NzT7+ACcDoJv
zC58EcBmg/mBcK9QH04H25Y=
=Yb//
-----END PGP SIGNATURE-----

This is a good idea.
I had done something like that for the original axis('equal') and
axis('scaled') but I don't think it is in the example directory anymore.
Once we get it to work again, I will make sure to do make an example and put
it in the units directory.
And Yes, I realize testing this stuff in interactive mode is not easy.
Eric has done a very nice job rewriting my original stuff in an organized
and much more comprehensive fashion. These are just some last minor issues
that need to be fixed.
Mark
On 2/15/07, John Hunter <jd...@gm...> wrote:
>
> On 2/15/07, Mark Bakker <ma...@gm...> wrote:
> > I found another problem that I cannot figure out.
> > I make an axis, and make it 'scaled'.
>
> Unit testing graphics packages can be hard, especially interactive
> stuff like this, but I am a fan of poor man's unit testing here. When
> you get something working like you like it, write an example that
> generates several figures, and make the figure title an instruction to
> the user, like: "zoom the image and the axes aspect should update" and
> that way when other developers make changes down the road they can
> make sure all the original features are preserved.
>
> These scripts can be put into the units directory of the svn repository.
>
> JDH
>

On 2/15/07, Delbert Franz <dd...@lk...> wrote:
> I'm back to developing with matplotlib after a bit of a hiatus. I am
> refactoring an app I wrote about two years ago. I suspect I have uncovered
> a bug in 0.90 which was not present in 0.87.7. The small test script,
> which I created to reproduce the problem, fails with the follow traceback
> in 0.90:
>
Yes, I discovered that myself yesterday -- fixed in svn.
Thanks for the report.
JDH

On 2/15/07, Mark Bakker <ma...@gm...> wrote:
> I found another problem that I cannot figure out.
> I make an axis, and make it 'scaled'.
Unit testing graphics packages can be hard, especially interactive
stuff like this, but I am a fan of poor man's unit testing here. When
you get something working like you like it, write an example that
generates several figures, and make the figure title an instruction to
the user, like: "zoom the image and the axes aspect should update" and
that way when other developers make changes down the road they can
make sure all the original features are preserved.
These scripts can be put into the units directory of the svn repository.
JDH

Eric -
I found another problem that I cannot figure out.
I make an axis, and make it 'scaled'.
Then I make a second axis that shares the x-axis with the first axis.
But then the y limits of the first axis change upon creation, and the
'adjustable' attribute!
I know for sure this used to work, but am not sure when it got changed.
What it used to do is that you could zoom nicely into the first axis
(interactively), while the size of the shared axis changed with it. A thing
of beauty I thought, and I loved showing it off. Do you think we can get
that back?
Here's a small example of the error:
>>> from pylab import *
>>> ax = axes([.1,.5,.8,.4])
>>> plot([1,2,3])
[<matplotlib.lines.Line2D instance at 0x01C38800>]
>>> axis('scaled')
(0.0, 2.0, 1.0, 3.0)
>>> ax.get_adjustable()
'box'
>>> ax2 = axes([.1,.1,.8,.3],sharex=ax)
>>> ax.get_adjustable() # GOT CHANGED!
'datalim'
Mark

Hallo Darren,
thank you for your support, it seems I made a simple mistake
>>in the original "embedding_in_qt.py" function compute_initial_figure:
>>
>>self.axes.set_xlabel("label")
>>
>>the label is not displayed.
> 
> 
I placed the "self.axes.set_xlabel("label")" before the self.axes.plot.
if order is changed everything works as expected.
Thank you
Gerhard
-- 
Gerhard Spitzlsperger
Renesas Semiconductor Europe (Landshut) GmbH
Senior Advisor Process
Jenaer Strasse 1
Germany 84034 Landshut
Tel +(49) 871 684 342
Fax +(49) 871 684 150
-----------------------------------------
The road goes ever on and on
 down from the door where it began.
Now far ahead the road has gone,
 and I must follow, if I can
****************************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on
it, is prohibited.
E-mail messages are not necessarily secure. Renesas does not accept
responsibility for any changes made to this message after it was sent.
Please note that this email message has been swept by Renesas for
the presence of computer viruses.
Renesas Semiconductor Europe (Landshut) GmbH
Jenaer Strasse 1, 84034 Landshut
Tel.: +49-(0)871-684-0, Fax: +49-(0)871-684-150
www.rsel.renesas.com
GESCHAEFTSFUEHRER: Dipl.-Ing. YOSHIHARU KAKUI
 Dipl.-Phys. STEFAN SAUER
Registergericht Landshut HRB 1464
Ust-ldNr.: DE 128953054 Steuer-Nr.: 132/136/30347
HypoVereinsbank, Landshut, Kto.-Nr. 3704 700 (BLZ 743 200 73) 
Mizuho Corporate Bank (Germany) AG, Frankfurt, Kto.-Nr. 200 733 (BLZ 503 308 00)
****************************************************************************

Eric -
Thanks for your reply.
Let me give you my idea about axis('scaled') and why I am asking for a
change (a new option would be fine as well).
What people I talked to do is, they plot some background (say roads) for a
large area; in interactive mode. Then they contour a small portion of that
area, for which they made a model, and zoom in. Then they realize: oh, I
haven't set the aspect ratio, so they do axis('scaled') and boom, they are
zoomed out again to the full extend of all the roads they have as a
background. This is a surprisingly common, and I see it a lot, also with
people using Matlab. It drives you bonkers. If you use axis('equal'), also
in Matlab, every time you add something to the plot, it zooms out to the
full extend again. And drives you up the wall. That's is why I made
axis('scaled'). I want to use the axis limits the user has specified and not
monckey with it. That works fine now (thanks!), except for the very first
time you do axis('scaled'), then it zooms out to the full extend. It doesn't
make much sense to me to do it the first time, but not any of the other
times.
I hope this makes some sense. So what to do next. My preference is to make
the change I suggested. My second choice is to define a new option that does
what I request, as I think this will get a lot of use. Then we would have to
come up with a new option name.
Let me know what you think,
Mark
On 2/14/07, Eric Firing <ef...@ha...> wrote:
>
> Mark,
>
> It sounds like what you want axis('scaled') to do is nothing other than
>
> gca().set_aspect(1, adjustable='box')
> draw_if_interactive()
>
> I think this is a bit out of character with things like axis('equal').
> Part of this character is that automatic things are turned on, so that
> going back and forth between axis('equal') and axis('scaled') switches
> back and forth between the same two plots; the result is not
> history-dependent.
>
> At your request (between the 0.87.7 and 0.90 releases), I put in a
> little bit of history-dependence by making axis('scaled') call to
> self.set_autoscale_on(False) # Req. by Mark Bakker
> after the set_aspect() call. This means that you can get the behavior
> you want simply by changing your example to
>
> from pylab import *
> plot([1,2,3],[1,2,1])
> axis('scaled')
> axis([1,2,1,2]) # define new axis limits
>
> Is this good enough? Do you really need to be able to set the axis
> limits *before* the call to axis('scaled')? If so, then I am inclined
> to make this a separate option for the axis command, because I think the
> present behavior of axis('scaled') is sensible in the context of the
> other existing options.
>
> Eric
>
>
> Mark Bakker wrote:
> > Eric -
> >
> > I just installed version 0.90 on my windows machine and it seems that
> > axis('scaled') doesn't work properly yet.
> > I thought axis('scaled') will change the axes such that the aspect ratio
> > is equal WITHOUT changing the limits on the axes.
> > A simple example shows that this goes wrong (I thought this used to
> work):
> >
> > from pylab import *
> > plot([1,2,3],[1,2,1])
> > axis([1,2,1,2]) # define new axis limits
> > axis('scaled')
> >
> > And now Python comes back with ( 1.0, 3.0, 0.80000000000000004, 2.0),
> > which are the limits of the original plot command obtained using
> > autoscale_view.
> > I think this is an easy fix in the axis function of axes.py.
> > Here you do an autoscale_view, which shouldn't be done in the 'scaled'
> > option.
> > I think you only need to change the indicated line below.
> >
> > Thanks,
> >
> > Mark
> >
> > def axis(self, *v, **kwargs):
> > '''
> > Convenience method for manipulating the x and y view limits
> > and the aspect ratio of the plot.
> >
> > kwargs are passed on to set_xlim and set_ylim -- see their
> > docstrings for details
> > '''
> > if len(v)==1 and is_string_like(v[0]):
> > s = v[0].lower()
> > if s=='on': self.set_axis_on()
> > elif s=='off': self.set_axis_off()
> > elif s in ('equal', 'tight', 'scaled', 'normal', 'auto',
> > 'image'):
> > self.set_autoscale_on(True)
> > self.set_aspect('auto')
> > if s!= 'scaled': self.autoscale_view() # THIS LINE WAS
> > CHANGED BY ADDING THE IF STATEMENT
> > self.apply_aspect()
> > if s=='equal':
> > self.set_aspect('equal', adjustable='datalim')
> > elif s == 'scaled':
> > self.set_aspect ('equal', adjustable='box',
> anchor='C')
> > self.set_autoscale_on(False) # Req. by Mark Bakker
> > elif s=='tight':
> > self.autoscale_view (tight=True)
> > self.set_autoscale_on(False)
> > elif s == 'image':
> > self.autoscale_view(tight=True)
> > self.set_autoscale_on(False)
> > self.set_aspect('equal', adjustable='box',
> anchor='C')
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> > opinions on IT & business topics through brief surveys-and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Hi Chris,
Christopher Barker wrote:
> Thanks for doing this, the wx back-ends are a bit neglected at the 
> moment.
>
> Which version of wxPython did you test this all on? We really need 
> some work/testing with 2.8.*, I now there are some issues on OS-X, but 
> I haven't tried it anywhere else yet.
Tests were done with:
# Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]
# wxPython 2.8.1.1, Boa Constructor 0.5.2
That is the ANSI build of wxPython. As soon as there is a matplotlib 
build with 2.8 I will do more testing, can then use either ANSI or Unicode.
Werner

I'm back to developing with matplotlib after a bit of a hiatus. I am 
refactoring an app I wrote about two years ago. I suspect I have uncovered
a bug in 0.90 which was not present in 0.87.7. The small test script,
which I created to reproduce the problem, fails with the follow traceback
in 0.90:
ddf@ax2:$ python debug.py 
Traceback (most recent call last):
 File "debug.py", line 43, in ?
 plot_date(jt2, f2, ':')
 File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line 
2064, in plot_date
 ret = gca().plot_date(*args, **kwargs)
 File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 2395, 
in plot_date
 self.xaxis_date(tz)
 File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1564, 
in xaxis_date
 formatter = AutoDateFormatter(locator)
UnboundLocalError: local variable 'locator' referenced before assignment
but running in 0.87.7 produces a figure with two traces. If only one
trace is done, 0.90 produces a figure. 
I can drop back to 0.87.7 but I would prefer to continue working with 0.90.
Glad to be back using Python and matplotlib!
I'm running on Debian Etch on both machines. 0.90 is compiled from the latest
tarball since Etch only has 0.87.7 available.
 Delbert