matplotlib-users Mailing List for matplotlib

Russell and Eric, many thanks for sticking with me on this issue. I've 
been able to reproduce the problem just by calling gc.collect() without 
loading Matplotlib, so it looks like the problem is elsewhere. I'm very 
sorry I didn't realize this sooner.
Cheers,
Anand

Thanks for the reply. =0A=0AI saw Chris's note after I posted my last emai=
l and yes I think that link is very helpful. I am studying that link and I=
 think I know what to do now.=0A=0AThanks again (to Chris as well).=0A=0A=
=0A> -----Original Message-----=0A> From: Darren Dale [mailto:dd55@cornell.=
edu] =0A> Sent: Wednesday, February 21, 2007 2:40 PM=0A> To: matplotlib-use=
rs...@li...=0A> Cc: kc1...@ya...=0A> Subjec=
t: Re: [Matplotlib-users] Maximized vs non-maximized output=0A> =0A> =0A> O=
n Wednesday 21 February 2007 05:10:57 pm =0A> kc106_2005-matplotlib@yahoo.c=
om =0A> wrote:=0A> > Okay, I uploaded another set of plots. Please take a =
look at them =0A> > again.=0A> > I hope it's clear this time.=0A> =0A> It i=
s not. This discussion is semantic; it is not clear what =0A> you find ugly=
 =0A> about your "ugly" plots. If you don't like the size of your =0A> font=
s, and the =0A> thickness of your lines, you can alter them or change your =
=0A> defaults with rc =0A> settings.=0A> =0A> > I must reiterate that the *=
only* thing I did different =0A> between the 2 =0A> > was to do a screen m=
aximize before saving - and the fonts, lines, =0A> > spacing all came out c=
orrect. I did not change font or anything in =0A> > the code.=0A> =0A> Yes=
, you have made that clear. If you want to know why =0A> maximizing the win=
dow =0A> changes the output, you should read through the link that =0A> Chr=
is posted in =0A> this thread.=0A> =0A=0A--=0AJohn Henry=0A=0A=0A=0A=0A

 From the matplotlib-devel list:
 >On 2/14/07, Michiel Jan Laurens de Hoon <mdehoon@c2...> wrote:
 >> Dear Charles,
 >>
 >> I was trying to use your cocoa-agg backend for matplotlib, but it seems
 >> to have a problem to read Matplotlib.nib. Opening this nib with
 >> Interface Builder also gives an error. It appears that the problem is
 >> caused by the file keyedobjects.nib in the Matplotlib.nib folder. If I
 >> run plutil on keyedobjects.nib, it crashes. The other two files in
 >> Matplotlib.nib look fine. So I was wondering if it is possible that the
 >> keyedobjects.nib file included in matplotlib is damaged. If so, do you
 >> have a valid copy of this file?
 >>
 >> Many thanks in advance,
 >>
 >> --Michiel de Hoon.
 >
 >We recently moved the data files, and I think the nib files got
 >interpreted as text instead of binary files. I grabbed an old copy
 >from a previous source release and committed them as binary. They
 >should work now.
 >
 >- Charlie
I just downloaded 
/trunk/matplotlib/lib/matplotlib/backends/Matplotlib.nib, rev 3022 on 
svn. When I tried to use it, this happened:
In [1]: figure()
2007年02月21日 15:00:51.611 Python[813] *** NSThread: ignoring exception 
'*** -[NSKeyedUnarchiver decodeObjectForKey:]: missing class information 
for object' that raised during delayed perform of target 0x3b308c0 and 
selector 'startWithBundle:'
I wasn't able to open the nib package with the interface builder, and 
plutil crashed on keyedobjects.nib (I don't know what plutil is supposed 
to do). I'm using a PPC G4 running OS X 10.4.
Thanks much,
Anand

On Wednesday 21 February 2007 05:10:57 pm kc1...@ya... 
wrote:
> Okay, I uploaded another set of plots. Please take a look at them again. 
> I hope it's clear this time.
It is not. This discussion is semantic; it is not clear what you find ugly 
about your "ugly" plots. If you don't like the size of your fonts, and the 
thickness of your lines, you can alter them or change your defaults with rc 
settings.
> I must reiterate that the *only* thing I did different between the 2 was to
> do a screen maximize before saving - and the fonts, lines, spacing all
> came out correct. I did not change font or anything in the code.
Yes, you have made that clear. If you want to know why maximizing the window 
changes the output, you should read through the link that Chris posted in 
this thread.
> > -----Original Message-----
> > From: mat...@li...
> > [mailto:mat...@li...] On
> > Behalf Of Darren Dale
> > Sent: Wednesday, February 21, 2007 1:23 PM
> > To: mat...@li...
> > Subject: Re: [Matplotlib-users] Maximized vs non-maximized output
> >
> >
> > On Wednesday 21 February 2007 03:44:56 pm
> > kc1...@ya...
> >
> > wrote:
> > > Okay, I posted the "ugly" vs "pretty" plots at:
> > >
> > > http://new.photos.yahoo.com/kimwaic106/album
> > >
> > > I stripped out most of the titles and subtitles but I think you can
> > > still see the difference between the two. (Don't worry about the
> > > middle unintelligble part).
> >
> > I dont really see any difference between these two plots,
> > aside from the
> > obvious and expected difference in font size and line width.
> > If you want to
> > pursue this further, please try to be more descriptive than "ugly"
> > and "pretty".

Okay, I uploaded another set of plots. Please take a look at them again. =
I hope it's clear this time.=0A=0AI must reiterate that the *only* thing I =
did different between the 2 was to do a screen maximize before saving - an=
d the fonts, lines, spacing all came out correct. I did not change font or=
 anything in the code.=0A=0A> -----Original Message-----=0A> From: matplotl=
ib-...@li... =0A> [mailto:matplotlib-users-bounce=
s...@li...] On =0A> Behalf Of Darren Dale=0A> Sent: Wednesday,=
 February 21, 2007 1:23 PM=0A> To: mat...@li...=
=0A> Subject: Re: [Matplotlib-users] Maximized vs non-maximized output=0A> =
=0A> =0A> On Wednesday 21 February 2007 03:44:56 pm =0A> kc106_2005-matplot=
li...@ya... =0A> wrote:=0A> > Okay, I posted the "ugly" vs "pretty" plots=
 at:=0A> >=0A> > http://new.photos.yahoo.com/kimwaic106/album=0A> >=0A> > I=
 stripped out most of the titles and subtitles but I think you can =0A> > s=
till see the difference between the two. (Don't worry about the =0A> > mid=
dle unintelligble part).=0A> =0A> I dont really see any difference between =
these two plots, =0A> aside from the =0A> obvious and expected difference i=
n font size and line width. =0A> If you want to =0A> pursue this further, p=
lease try to be more descriptive than "ugly" =0A> and "pretty".=0A> =0A> Da=
rren=0A=0A =0A--=0AJohn Henry=0A=0A

Darren Dale wrote:
> I dont really see any difference between these two plots, aside from the 
> obvious and expected difference in font size and line width.
I suspect that is the OP's issue. Maybe this will help:
http://www.scipy.org/Cookbook/Matplotlib/AdjustingImageSize
-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...

On Wednesday 21 February 2007 03:44:56 pm kc1...@ya... 
wrote:
> Okay, I posted the "ugly" vs "pretty" plots at:
>
> http://new.photos.yahoo.com/kimwaic106/album
>
> I stripped out most of the titles and subtitles but I think you can still
> see the difference between the two. (Don't worry about the middle
> unintelligble part).
I dont really see any difference between these two plots, aside from the 
obvious and expected difference in font size and line width. If you want to 
pursue this further, please try to be more descriptive than "ugly" 
and "pretty".
Darren

On Feb 21, 2007, at 1:58 PM, Christopher Barker wrote:
> Werner F. Bruhin wrote:
>>
>> Is there a list of what the problems are?
>
> One is that it won't build, due to a code error in the extension -- I
> don't know why that same error didn't cause a problem with earlier
> versions of wxPython.
The WXAgg backend itself should still function without _wxagg.so, 
which exists slowly to speed up the Agg/wx.Image/wx.Bitmap tango. I 
tried to get it up and running on OSX with wxPython 2.8 earlier today 
but was quickly stymied by an inscrutable problem with 
wxPyConstructObject(). Since I'd like to start moving away from 
using a C++ extension in the backend, I'm going to try to re- 
implement its functionality using the new wx.BitmapFromBufferRGBA().
> The other I know about is some oddities with the toolbar on OS-X -- I
> think those are OS-X only issues.
Once I have the WXAgg accelerator straightened out, I'll see if I can 
reproduce and fix this problem.
Ken

Okay, I posted the "ugly" vs "pretty" plots at:=0A=0Ahttp://new.photos.yaho=
o.com/kimwaic106/album=0A=0AI stripped out most of the titles and subtitles=
 but I think you can still see the difference between the two. (Don't worr=
y about the middle unintelligble part).=0A=0ARegards,=0A =0A--=0AJohn Henry=
=0A=0A----- Original Message ----=0AFrom: "kc1...@ya..."=
 <kc1...@ya...>=0ATo: mat...@li...urceforge=
.net=0ASent: Wednesday, February 21, 2007 11:37:54 AM=0ASubject: Re: [Matpl=
otlib-users] Maximized vs non-maximized output=0A=0AOkay, I tried saving us=
ing the postscript format, and I end up with the "ugly" plot also. In fac=
t, if I maximize the plot and then save as .ps file, I get ugly plot as wel=
l. So, saving it in PS made no difference - that part is correct but it me=
ans I end up with the same font, and dimension as the non-maximized versio=
n.=0A=0ASomehow, if I maximize the plot using the show() command, maximize =
it first, then save it (in png format), I end up with a very nice looking p=
lot. I just wish there is a simple way to accomplish that in batch mode.=
=0A=0ARegards,=0A =0A--=0AJohn Henry=0A=0A----- Original Message ----=0AFro=
m: "kc1...@ya..." <kc1...@ya...>=0ATo=
: mat...@li...=0ASent: Wednesday, February 21, 20=
07 11:17:18 AM=0ASubject: Re: [Matplotlib-users] Maximized vs non-maximized=
 output=0A=0AThanks for the reply, Darren.=0A=0AI didn't post the plot beca=
use I don't know if the list accept email attachments, and I don't have any=
 space on the web for file sharing.=0A=0AI'll try to figure out a way to po=
st the plots.=0A=0ABTW: I called savefig with the filename, and a dpi of 60=
0 and nothing else. May be that was the problem.=0A=0ARegards,=0A=0A> ----=
-Original Message-----=0A> From: Darren Dale [mailto:dd...@co...] =0A>=
 Sent: Wednesday, February 21, 2007 10:54 AM=0A> To: matplotlib-users@lists=
.sourceforge.net=0A> Cc: kc1...@ya...=0A> Subject: Re: [=
Matplotlib-users] Maximized vs non-maximized output=0A> =0A> =0A> On Wednes=
day 21 February 2007 01:40:59 pm =0A> kc1...@ya... =0A> =
wrote:=0A> > Hi list,=0A> >=0A> > I am still fairly new to Matplotlib.=0A> =
>=0A> > If I use the default settings, after creating a plot, and save the =
=0A> > file, I get a .png file that looks really ugly. However, if I view =
=0A> > the plot at the screen first (using the show() command), =0A> maximi=
zed the =0A> > plot, and then save the file, I get a very nice looking =0A>=
 .png file. If =0A> > I am doing lots of plots, obviously I don't want to =
have to =0A> sit there =0A> > and view each and every plots, maximize, save=
, ...=0A> >=0A> > How can I accomplish this in batch mode?=0A> =0A> We coul=
d probably be of more help if you posted examples of =0A> your "ugly" =0A> =
and "nice" pngs. For now I'll take a guess: maybe what you =0A> are seeing =
is an =0A> effect of the resolution and figure size? You can pass a dpi =0A=
> kwarg to the =0A> savefig command, or you can set it in your rc settings.=
 Also, =0A> you can set the =0A> figure size by doing "figure(figsize=3D(x,=
y))", or you can =0A> change the default =0A> figure size in your rc settin=
gs. How does your postscript =0A> output look? That =0A> format would not b=
e influenced by resolution.=0A> =0A> Darren=0A> =0A =0A--=0AJohn Henry=0A=
=0A=0A=0A=0A=0A=0A=0A

Hi,
 I would like to add another annoying aspect of the "digits in the GUI":
When a log axis is used the displayed numbers looks like 10^-8.23
which is definitely not human readable.
Do somebody know a quick fix to obtain something like 5.89e-9 or 5.89x10^-9 ?
Thanks,
David

Werner F. Bruhin wrote:
> If someone can do a Windows build against a wxPython 2.8 version (and 
> Python 2.5) I could do some testing.
> 
> Is there a list of what the problems are?
no.
One is that it won't build, due to a code error in the extension -- I 
don't know why that same error didn't cause a problem with earlier 
versions of wxPython.
The other I know about is some oddities with the toolbar on OS-X -- I 
think those are OS-X only issues.
-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...

Okay, I tried saving using the postscript format, and I end up with the "ug=
ly" plot also. In fact, if I maximize the plot and then save as .ps file,=
 I get ugly plot as well. So, saving it in PS made no difference - that pa=
rt is correct but it means I end up with the same font, and dimension as t=
he non-maximized version.=0A=0ASomehow, if I maximize the plot using the sh=
ow() command, maximize it first, then save it (in png format), I end up wit=
h a very nice looking plot. I just wish there is a simple way to accomplis=
h that in batch mode.=0A=0ARegards,=0A =0A--=0AJohn Henry=0A=0A----- Origin=
al Message ----=0AFrom: "kc1...@ya..." <kc106_2005-matpl=
ot...@ya...>=0ATo: mat...@li...=0ASent: Wedne=
sday, February 21, 2007 11:17:18 AM=0ASubject: Re: [Matplotlib-users] Maxim=
ized vs non-maximized output=0A=0AThanks for the reply, Darren.=0A=0AI didn=
't post the plot because I don't know if the list accept email attachments,=
 and I don't have any space on the web for file sharing.=0A=0AI'll try to f=
igure out a way to post the plots.=0A=0ABTW: I called savefig with the file=
name, and a dpi of 600 and nothing else. May be that was the problem.=0A=
=0ARegards,=0A=0A> -----Original Message-----=0A> From: Darren Dale [mailto=
:dd...@co...] =0A> Sent: Wednesday, February 21, 2007 10:54 AM=0A> To:=
 mat...@li...=0A> Cc: kc106_2005-matplotlib@yahoo=
.com=0A> Subject: Re: [Matplotlib-users] Maximized vs non-maximized output=
=0A> =0A> =0A> On Wednesday 21 February 2007 01:40:59 pm =0A> kc106_2005-ma=
tpl...@ya... =0A> wrote:=0A> > Hi list,=0A> >=0A> > I am still fairly=
 new to Matplotlib.=0A> >=0A> > If I use the default settings, after creati=
ng a plot, and save the =0A> > file, I get a .png file that looks really ug=
ly. However, if I view =0A> > the plot at the screen first (using the show=
() command), =0A> maximized the =0A> > plot, and then save the file, I get =
a very nice looking =0A> .png file. If =0A> > I am doing lots of plots, ob=
viously I don't want to have to =0A> sit there =0A> > and view each and eve=
ry plots, maximize, save, ...=0A> >=0A> > How can I accomplish this in batc=
h mode?=0A> =0A> We could probably be of more help if you posted examples o=
f =0A> your "ugly" =0A> and "nice" pngs. For now I'll take a guess: maybe w=
hat you =0A> are seeing is an =0A> effect of the resolution and figure size=
? You can pass a dpi =0A> kwarg to the =0A> savefig command, or you can set=
 it in your rc settings. Also, =0A> you can set the =0A> figure size by doi=
ng "figure(figsize=3D(x,y))", or you can =0A> change the default =0A> figur=
e size in your rc settings. How does your postscript =0A> output look? That=
 =0A> format would not be influenced by resolution.=0A> =0A> Darren=0A> =0A=
 =0A--=0AJohn Henry=0A=0A=0A=0A=0A

Thanks for the reply, Darren.=0A=0AI didn't post the plot because I don't k=
now if the list accept email attachments, and I don't have any space on the=
 web for file sharing.=0A=0AI'll try to figure out a way to post the plots.=
=0A=0ABTW: I called savefig with the filename, and a dpi of 600 and nothing=
 else. May be that was the problem.=0A=0ARegards,=0A=0A> -----Original Mes=
sage-----=0A> From: Darren Dale [mailto:dd...@co...] =0A> Sent: Wednes=
day, February 21, 2007 10:54 AM=0A> To: mat...@li...urceforge.=
net=0A> Cc: kc1...@ya...=0A> Subject: Re: [Matplotlib-us=
ers] Maximized vs non-maximized output=0A> =0A> =0A> On Wednesday 21 Februa=
ry 2007 01:40:59 pm =0A> kc1...@ya... =0A> wrote:=0A> > =
Hi list,=0A> >=0A> > I am still fairly new to Matplotlib.=0A> >=0A> > If I =
use the default settings, after creating a plot, and save the =0A> > file, =
I get a .png file that looks really ugly. However, if I view =0A> > the pl=
ot at the screen first (using the show() command), =0A> maximized the =0A> =
> plot, and then save the file, I get a very nice looking =0A> .png file. =
If =0A> > I am doing lots of plots, obviously I don't want to have to =0A> =
sit there =0A> > and view each and every plots, maximize, save, ...=0A> >=
=0A> > How can I accomplish this in batch mode?=0A> =0A> We could probably =
be of more help if you posted examples of =0A> your "ugly" =0A> and "nice" =
pngs. For now I'll take a guess: maybe what you =0A> are seeing is an =0A> =
effect of the resolution and figure size? You can pass a dpi =0A> kwarg to =
the =0A> savefig command, or you can set it in your rc settings. Also, =0A>=
 you can set the =0A> figure size by doing "figure(figsize=3D(x,y))", or yo=
u can =0A> change the default =0A> figure size in your rc settings. How doe=
s your postscript =0A> output look? That =0A> format would not be influence=
d by resolution.=0A> =0A> Darren=0A> =0A =0A--=0AJohn Henry=0A=0A

On Wednesday 21 February 2007 01:40:59 pm kc1...@ya... 
wrote:
> Hi list,
>
> I am still fairly new to Matplotlib.
>
> If I use the default settings, after creating a plot, and save the file, I
> get a .png file that looks really ugly. However, if I view the plot at the
> screen first (using the show() command), maximized the plot, and then save
> the file, I get a very nice looking .png file. If I am doing lots of
> plots, obviously I don't want to have to sit there and view each and every
> plots, maximize, save, ...
>
> How can I accomplish this in batch mode?
We could probably be of more help if you posted examples of your "ugly" 
and "nice" pngs. For now I'll take a guess: maybe what you are seeing is an 
effect of the resolution and figure size? You can pass a dpi kwarg to the 
savefig command, or you can set it in your rc settings. Also, you can set the 
figure size by doing "figure(figsize=(x,y))", or you can change the default 
figure size in your rc settings. How does your postscript output look? That 
format would not be influenced by resolution.
Darren

Chris Barker wrote:
> Russell E Owen wrote:
>
> 
>> I did earlier today; I'm hoping it will go up in the next day or so.
>>
>> WXAgg is built against wxPython 2.6.x because last I heard the 2.8.x 
>> issues weren't resolved.
>> 
>
> Correct. I'm still not sure how well MPL works with wxPython2.8 on other 
> platforms, but no one has fixed the issues on OS-X yet. There is 
> something weird with toolbars with wxPython2.8, I've run into that with 
> some other code, so it may even take a new release of wxPython to get it 
> all right. Of course, that wont' do it if I dont' get around to fiing a 
> bug report!
>
> wxPython includes a wxversion module that lets one select whihc version 
> of wxPython you want run, if more than one is installed. It might be 
> nice if those calls could get put into MPL somewhere, so that when MPL 
> is built against a given version, that version will be run.
> 
If someone can do a Windows build against a wxPython 2.8 version (and
Python 2.5) I could do some testing.
Is there a list of what the problems are?
Werner

Hi list,=0A=0AI am still fairly new to Matplotlib. =0A=0AIf I use the defa=
ult settings, after creating a plot, and save the file, I get a .png file t=
hat looks really ugly. However, if I view the plot at the screen first (us=
ing the show() command), maximized the plot, and then save the file, I get =
a very nice looking .png file. If I am doing lots of plots, obviously I do=
n't want to have to sit there and view each and every plots, maximize, save=
, ... =0A=0AHow can I accomplish this in batch mode?=0A=0AThanks,=0A =0A--=
=0AJohn Henry=0A=0A

In article <45D...@cs...>,
 Anand Patil <an...@so...> wrote:
> >>Matplotlib occasionally crashes Python at the end of a long program on 
> >>my powerbook g4 running OS X 10.4. gdb output follows:
> >>
...
> It's Python 2.5, and the new Matplotlib 0.9 built from source. I saw the 
> same problem with Python 2.4.3 and Matplotlib 0.8.(can't remember), 
> which was part of the reason I upgraded. However, I didn't look at the 
> problem with gdb using the earlier versions.
Could you please try the matplotlib 0.90.0 binary for Python 2.5 from 
<http://pythonmac.org/packages/> and let us know if that also has the 
problem?
Also, could this be a memory leak? You may want to watch Activity 
Monitor or top while running your program.
If you do still have problems it might help to know a few more things 
including:
- which Python 2.5? (MacPython? fink? ActiveState?...)
- which back end and which numerix (and have you tried any other 
combinations?)
If that solves the problem then you may want to review instructions for 
building matplotlib for MacOS X, e.g.:
<http://www.astro.washington.edu/rowen/BuildingMatplotlibForMac.html>
-- Russell

At 9:42 AM -0800 2007年02月21日, Chris Barker wrote:
>Russell E Owen wrote:
>
>>I did earlier today; I'm hoping it will go up in the next day or so.
>>
>>WXAgg is built against wxPython 2.6.x because last I heard the 
>>2.8.x issues weren't resolved.
>
>Correct. I'm still not sure how well MPL works with wxPython2.8 on 
>other platforms, but no one has fixed the issues on OS-X yet. There 
>is something weird with toolbars with wxPython2.8, I've run into 
>that with some other code, so it may even take a new release of 
>wxPython to get it all right...
Thank you for the update.
FYI: matplotlib 0.90.0 for Python 2.5 is now available at 
<http://pythonmac.org/packages>. I did not build a version for Python 
2.4.
Regards,
-- Russell

There's probably a better forum for this conversation, but...
Barry Wark wrote:
> Perhaps we should consider two use cases: interactive use ala Matlab
> and larger code bases.
A couple key points -- yes, interactive use is different than larger 
code bases, but I think it's a "Bad Idea" to promite totally different 
coding styles for these cases for a couple reasons:
-- One usually is doing both at once. I was a long-time, every day 
Matlab user, and hardly did anything of consequence interactively. I 
learned very quickly that it made a whole lot more sense to write a five 
line script that I could save, edit, etc. than do stuff interactively. 
Once I got something working, parts of that five line script might get 
cut&pasted into "real" code.
I do still test one or two lines interactively, but even then, I want 
the style to be something I can put in my code.
2) consistency in docs and examples is important, recommending different 
styles for interactive and programming use is just going to confuse 
people more.
3) even for folks that do a lot of interactive use, they are likely to 
write larger scale code at some point, and then they would need to learn 
something new.
> In the first case, being able to import * saves
> a lot of typing
No, it saves a little typing, if you're using an OOO style anyway.
 > and the namespace polution problem isn't a big deal.
Yes, it can be. A good interactive environment will be able to do things 
like method and command completion -- namespace pollution keeps that 
from working well.
> Returning to the OP's questions, why couldn't both cases be helped by
> creating a "meta-package" for numpy, scipy, and matplotlib? For the
> sake of argument, lets call the package "plab". Existing code could be
> affected by changing the individual packages, but a package that
> essentially does
> 
> from pylab import *
> from numpy import *
> from scipy import *
The issue with this is that you've now hidden where things are coming 
from. People seeing examples using that package will have no idea where 
things come from.
and by the way, the current "pylab", as delivered with MPL, pretty much 
does this already. I think we need to move away from that, rather than 
putting even more into pylab.
Matthew Brett wrote:
> The downside about making numpy / python like matlab is that
> you soon realize that you really have to think about your problems
> differently, and write code in a different way.
Good point. A part of good Pythonic code is namespaces and OOO style. 
New users might as well learn the whole pile at once.
That all being said, it would be nice to establish a standard convention 
for how to import the key packages. I use:
import numpy as N
import matplotlib as MPL
But I don't really care that much, if we can come to any kind of 
community consensus, I'll follow it. The goal would be for all docs, 
Wiki entries, examples on the mailing lists, etc. to use the same style.
-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...

Russell E Owen wrote:
> I did earlier today; I'm hoping it will go up in the next day or so.
> 
> WXAgg is built against wxPython 2.6.x because last I heard the 2.8.x 
> issues weren't resolved.
Correct. I'm still not sure how well MPL works with wxPython2.8 on other 
platforms, but no one has fixed the issues on OS-X yet. There is 
something weird with toolbars with wxPython2.8, I've run into that with 
some other code, so it may even take a new release of wxPython to get it 
all right. Of course, that wont' do it if I dont' get around to fiing a 
bug report!
wxPython includes a wxversion module that lets one select whihc version 
of wxPython you want run, if more than one is installed. It might be 
nice if those calls could get put into MPL somewhere, so that when MPL 
is built against a given version, that version will be run.
-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...

On Wednesday 21 February 2007 2:45:25 am Eric Firing wrote:
> Matthew Auger wrote:
> > Ah...right. That works well enough (I believe that I originally had
> > editted backend_bases to circumvent the format_coord call--clearly not
> > the best solution)! I don't know of a good reason to *not* use the axis
> > formatting, but perhaps an rcparam could control this?
>
> I don't know what the historical reason for the present default is, but
> one candidate is speed: the coordinate numbers get reformatted and
> printed at a great rate as the cursor moves across a plot, so one might
> not want to have the formatting done by a big chunk of python code.
> format_data_short will typically be faster than format_data.
Here is the reason format_data_short was added: the x,y coordinates of the 
cursor used to be printed to 10 digits, something I added when I was working 
out the offset ticklabels for the x and y axis. These coordinates, when 
rendered into the toolbar, were causing the figure window to resize to make 
room for the numbers in the toolbar. format_data is also used to format the 
ticklabels, so John suggested the new method. At the time, we needed a quick 
work around. Maybe it's time to give it another look, and see if there is a 
better long-term solution.
Darren 

Chiara Caronna wrote:
> I have a problem with backend: by default it was Agg; i tried to change the 
> file .matplotlibrc and to put GTKAgg, but as I import pylab I got these 
> errors:
> File 
> "/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", 
> line 6, in ?
> import gobject
> ImportError: No module named gobject
> 
> What can I do?
Install PyGTK.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

I have a problem with backend: by default it was Agg; i tried to change the 
file .matplotlibrc and to put GTKAgg, but as I import pylab I got these 
errors:
>>>from pylab import *
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "/usr/local/lib/python2.4/site-packages/pylab.py", line 1, in ?
 from matplotlib.pylab import *
 File "/usr/local/lib/python2.4/site-packages/matplotlib/pylab.py", line 
220, in ?
 new_figure_manager, draw_if_interactive, show = pylab_setup()
 File 
"/usr/local/lib/python2.4/site-packages/matplotlib/backends/__init__.py", 
line 23, in pylab_setup
 globals(),locals(),[backend_name])
 File 
"/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 10, in ?
 from backend_gtk import gtk, FigureManagerGTK, FigureCanvasGTK,\
 File 
"/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", 
line 6, in ?
 import gobject
ImportError: No module named gobject
What can I do?
Thanks.
Chiara
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Matthew Auger wrote:
> Ah...right. That works well enough (I believe that I originally had 
> editted backend_bases to circumvent the format_coord call--clearly not 
> the best solution)! I don't know of a good reason to *not* use the axis 
> formatting, but perhaps an rcparam could control this?
I don't know what the historical reason for the present default is, but 
one candidate is speed: the coordinate numbers get reformatted and 
printed at a great rate as the cursor moves across a plot, so one might 
not want to have the formatting done by a big chunk of python code. 
format_data_short will typically be faster than format_data.
An rcParam certainly could be added, given sufficient demand.
Now, I'm wondering why the number of digits is actually important to 
you--are you writing those numbers down? If so, would you rather 
capture the numbers to a file upon clicking? examples/zoom_window.py 
shows how to grab the coordinates at which a button was clicked. There 
may be better examples, but this is the first one I found.
Eric

Anand Patil wrote:
>> Anand Patil wrote:
>> 
>>
>>>>> Matplotlib occasionally crashes Python at the end of a long program on 
>>>>> my powerbook g4 running OS X 10.4. gdb output follows:
>>>>>
>>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>>>> Reason: KERN_INVALID_ADDRESS at address: 0x0a68fe40
>>>>> 0x002eae50 in visit_decref (op=0x28a1cb0, data=0x0) at 
>>>>> /Users/ronald/Python/r25/Modules/gcmodule.c:270
>>>>> 270 /Users/ronald/Python/r25/Modules/gcmodule.c: No such file or 
>>>>> directory.
>>>>> in /Users/ronald/Python/r25/Modules/gcmodule.c
>>>>>
>>>>> or
>>>>>
>>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000056
>>>>> 0x002eae50 in visit_decref (op=0x28a17e0, data=0x0) at 
>>>>> /Users/ronald/Python/r25/Modules/gcmodule.c:270
>>>>> 270 in /Users/ronald/Python/r25/Modules/gcmodule.c
>>>>>
>>>>> It's always something like that, and it always happens after the little 
>>>>> Python icon starts bouncing around in the dock. I don't know anyone 
>>>>> named Ronald and no such directory exists on my machine.
>>>>> 
>>>>>
>>>>> 
>>>>>
>>>> What version of matplotlib, what version of Python and where did you 
>>>> them from from (build from source, some binary installer, fink...?)
>>>>
>>>> -- Russell
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 
>>>>
>>> It's Python 2.5, and the new Matplotlib 0.9 built from source. I saw the 
>>> same problem with Python 2.4.3 and Matplotlib 0.8.(can't remember), 
>>> which was part of the reason I upgraded. However, I didn't look at the 
>>> problem with gdb using the earlier versions.
>>> 
>>>
>> This still sounds like a problem in which some component was built with 
>> a different version of another component than the one you are actually 
>> running. Are you sure you have only the one version of mpl and one 
>> version of python, so that the former was compiled against the latter? 
>> And the same for numpy or Numeric or numarray?
>> 
>>
> Totally sure, I erased my old site-packages directory and started over. 
> I'm using the latest release of numpy.
> 
>> You might want to look back through the mailing list archive; there has 
>> been a lot of discussion recently about how to get a working combination 
>> of numpy and mpl on a Mac.
>> 
>>
> Will do.
> 
> Come to think of it, could this be a problem with Python itself? 
> gcmodule.c sounds like the garbage collector.
> 
Yes, but my guess is that gdb is pointing to a problem with garbage 
collection that is caused by an error or version mismatch elsewhere, 
most likely in extension code, not in Python itself.
Eric
> Thanks,
> Anand