matplotlib-devel Mailing List for matplotlib (Page 4)

On 2/12/07, Andrew Straw <str...@as...> wrote:
> IMO, the way to fix it is to move all the data into
> lib/matplotlib/mpl-data to start with. If we did that, all the shuffling
> that setup.py does would be unnecessary and using setuptools' develop
> mode would work out-of-the-box. I'd be happy to move these files in the
> svn repository if people agree this is a good idea.
I'm +1 on that. For some reason, I thought we had already decided to
do that when we moved to support setuptool in the first place.
JDH

John Hunter wrote:
> I am inclined to consider ripping out the __init__ stuff into a
> "config" module or something like that. 
+1

Jouni K. Seppänen wrote:
> "Nicolas Grilly" <nic...@ga...> writes:
>
> 
>> When you are working on matplotlib, after a checkout from the SVN
>> repository, which method do you use to compile extensions without
>> re-building and re-installing everything each time?
>> 
>
> I use "python setupegg.py develop", which I think does the same thing
> as build_ext --inplace. I have made a symbolic link for the mpl-data
> subdirectory. (Perhaps some setuptools wizard can tell us how to fix
> setupegg.py so that mpl-data gets installed in-place?)
IMO, the way to fix it is to move all the data into
lib/matplotlib/mpl-data to start with. If we did that, all the shuffling
that setup.py does would be unnecessary and using setuptools' develop
mode would work out-of-the-box. I'd be happy to move these files in the
svn repository if people agree this is a good idea.
-Andrew

"Nicolas Grilly" <nic...@ga...> writes:
> When you are working on matplotlib, after a checkout from the SVN
> repository, which method do you use to compile extensions without
> re-building and re-installing everything each time?
I use "python setupegg.py develop", which I think does the same thing
as build_ext --inplace. I have made a symbolic link for the mpl-data
subdirectory. (Perhaps some setuptools wizard can tell us how to fix
setupegg.py so that mpl-data gets installed in-place?)
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 2/11/07, Nicolas Grilly <nic...@ga...> wrote:
> When you are working on matplotlib, after a checkout from the SVN
> repository, which method do you use to compile extensions without
> re-building and re-installing everything each time?
I rebuild and reinstall each time. Since only the changed files are
built, this usually goes fairly quickly after a svn update. If you
ware working on extension code, it can get slow if you are building
the numpy, Numeric and numarray extensions each time. You can
manually override the NUMERIX list in setup.py to just build one of
the array extensions while developing, which should cut your compile
times.
JDH

Hello all,
When you are working on matplotlib, after a checkout from the SVN
repository, which method do you use to compile extensions without
re-building and re-installing everything each time?
For now, I use this method:
- I checkout matplotlib in directory c:\projects\matplotlib.
- I add c:\projects\matplotlib\lib to my PYTHONPATH.
- I use the command "python setup.py build_ext --inplace" each time I
modify a C/C++ file.
- Without anything else, I can use matplotlib in my scripts.
The problem:
This method builds smoothly my extensions (.pyd files) alongside my
Python files (.py files). But I have no directory
c:\projects\matplotlib\lib\matplotlib\mpl-data, like in a standard
installation. As a workaround, I've created it manually by copying
files from directory fonts and images.
My question:
Matplotlib's developers, how do you proceed on your own computer?
Thanks a lot for your answers,
Nicolas Grilly

Jörgen Stenarson <jor...@bo...> writes:
> Saving a semilogy plot using the [pdf] backend the exponents come
> out wrong.
This seems to have something to do with the caching in
Text._get_layout_super(). The first script below works right, the
second has the exponents all wrong.
------------------------------------------------------------------------
#!/usr/bin/env python
import matplotlib
matplotlib.use('pdf')
from matplotlib import pylab
pylab.plot([0.001, 1, 10, 100, 1000])
pylab.gca().set_yscale('log')
pylab.savefig('foo1.pdf')
------------------------------------------------------------------------
#!/usr/bin/env python
import matplotlib
matplotlib.use('agg')
from matplotlib import pylab
pylab.plot([0.001, 1, 10, 100, 1000])
pylab.gca().set_yscale('log')
pylab.savefig('foo2.pdf')
------------------------------------------------------------------------
For some reason this doesn't happen with the eps backend, even though
it has flipy() == False, like pdf and unlike agg. Is there something
the pdf backend should do to reset the state of other objects when
switching to pdf from another backend?
> Looking at the source for the pdf-backend I also saw that it contains
> a mix of space and tabs for indentation.
Fixed in svn.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

I forgot to mention, I'm running 0.87.7 in windows with WxAgg.
Martin
Martin Spacek wrote:
> Hello, just thought I should report two unexpected behaviours, which 
> took me a while to pinpoint:
> 
> 1) errorbar() plots the points but not the errorbars if axes.hold==False 
> for those axes (in my case, due to it being set to False in rcParams)
> 
> 2) when axes.hold is False, (again either set locally for the current 
> axes, or globally in rcParams), setting logscale _before_ calling bar() 
> raises a ValueError:
> 
> ValueError: Cannot set nonpositive limits with log transform
> 
> Setting it to logscale _after_ calling bar() prevents the error. Setting 
> axes.hold to True prevents the error in either case, even when setting 
> logscale _before_ calling bar(). I fear this behaviour may be related to 
> the couple of lines dealing with "holdstate" I submitted as part of a 
> patch last year to axes.bar
> 
> I think I may just set axes.hold back to the default True in my 
> rcParams, since it seems that's what most people use and test with. But, 
> it might be worthwhile to sort out any unintended behaviours when a user 
> decides to set their rcParams['axes.hold']=False.
> 
> Cheers,
> 
> Martin
> 
> 

Hello, just thought I should report two unexpected behaviours, which 
took me a while to pinpoint:
1) errorbar() plots the points but not the errorbars if axes.hold==False 
for those axes (in my case, due to it being set to False in rcParams)
2) when axes.hold is False, (again either set locally for the current 
axes, or globally in rcParams), setting logscale _before_ calling bar() 
raises a ValueError:
ValueError: Cannot set nonpositive limits with log transform
Setting it to logscale _after_ calling bar() prevents the error. Setting 
axes.hold to True prevents the error in either case, even when setting 
logscale _before_ calling bar(). I fear this behaviour may be related to 
the couple of lines dealing with "holdstate" I submitted as part of a 
patch last year to axes.bar
I think I may just set axes.hold back to the default True in my 
rcParams, since it seems that's what most people use and test with. But, 
it might be worthwhile to sort out any unintended behaviours when a user 
decides to set their rcParams['axes.hold']=False.
Cheers,
Martin

On Sun, Feb 11, 2007 at 01:32:45AM +1100, Tim Leslie wrote:
> Sorry, I think I might have given the wrong impression. Our use of an
> api.py is for having a single location to import classes equivalent to
> Figure, Axes, etc from. Your suggestion of having a matplotlib.config
> for things like rc and verbose makes a lot of sense I think.
Same missunderstanding here.
Gaël

On 2/11/07, John Hunter <jd...@gm...> wrote:
> On 2/10/07, Tim Leslie <tim...@gm...> wrote:
>
> > And for what it's worth this is also the direction nipy is taking,
> > having an api.py in each package.
>
> I don't have a problem with this if it makes sense to other people and
> helps with consistency across packages, but I don't find the mnemonic
> particularly clear. Eg
>
> from matplotlib.config import rc, verbose
>
> makes more sense to me than
>
> from matplotlib.api import rc, verbose
>
> since I consider these (and most other stuff in __init__) to be part
> of the configuration, and a lot of stuff that doesn't live there
> (Figure, Axes, Line2D) to be part of the API. What is the
> enthought/nipy rationale for calling it api?
>
Sorry, I think I might have given the wrong impression. Our use of an
api.py is for having a single location to import classes equivalent to
Figure, Axes, etc from. Your suggestion of having a matplotlib.config
for things like rc and verbose makes a lot of sense I think.
Tim
> JDH
>

On 2/10/07, Tim Leslie <tim...@gm...> wrote:
> And for what it's worth this is also the direction nipy is taking,
> having an api.py in each package.
I don't have a problem with this if it makes sense to other people and
helps with consistency across packages, but I don't find the mnemonic
particularly clear. Eg
 from matplotlib.config import rc, verbose
makes more sense to me than
 from matplotlib.api import rc, verbose
since I consider these (and most other stuff in __init__) to be part
of the configuration, and a lot of stuff that doesn't live there
(Figure, Axes, Line2D) to be part of the API. What is the
enthought/nipy rationale for calling it api?
JDH

On 2/11/07, Gael Varoquaux <gae...@no...> wrote:
> On Sat, Feb 10, 2007 at 08:04:38AM -0600, John Hunter wrote:
> > I am inclined to consider ripping out the __init__ stuff into a
> > "config" module or something like that.
>
> If my understanding is right, enthought does this with an "api" module.
> It might be worth going in the same direction.
>
And for what it's worth this is also the direction nipy is taking,
having an api.py in each package.
Tim
> My 2 cents,
>
> Ga=EBl
>
> --
> Gael Varoquaux,
> Groupe d'optique atomique,
> Laboratoire Charles Fabry de l'Institut d'Optique
> Campus Polytechnique, RD 128
> 91127 Palaiseau cedex FRANCE
> !!!! NEW Phone number !!!!
> Tel : 33 (0) 1 64 54 33 49 - Fax : 33 (0) 1 64 54 31 01
> Labs: 33 (0) 1 64 54 33 63 - 33 (0) 1 64 54 33 62
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Sat, Feb 10, 2007 at 08:04:38AM -0600, John Hunter wrote:
> I am inclined to consider ripping out the __init__ stuff into a
> "config" module or something like that. 
If my understanding is right, enthought does this with an "api" module.
It might be worth going in the same direction.
My 2 cents,
Gaël
 
-- 
 Gael Varoquaux,
 Groupe d'optique atomique,
 Laboratoire Charles Fabry de l'Institut d'Optique
 Campus Polytechnique, RD 128
 91127 Palaiseau cedex FRANCE
 !!!! NEW Phone number !!!!
 Tel : 33 (0) 1 64 54 33 49 - Fax : 33 (0) 1 64 54 31 01
 Labs: 33 (0) 1 64 54 33 63 - 33 (0) 1 64 54 33 62

On 2/9/07, Andrew Straw <str...@as...> wrote:
> It looks like we're on the hook for some bugs associated with our use of
> setuptools... I'm forwarding an email from the distutils-sig.
> The short of it is that Phillip Eby suggests we move matplotlib.toolkits
> to matplotlib_toolkits to save ourselves some grief. This does seem
> easier than the apparent alternative -- moving everything out of
> matplotlib/__init__.py.
I could go either way -- we are going to break a lot of code no matter
which way we do it. Ironically, and via a circuitous path, this is
ultimately my problem. The problem Phil is discussing was raised by
Skip on the distutils list. Skip works with me and is trying to
diagnose an MPL install problem I encountered at work yesterday and
asked for his input on.
I am inclined to consider ripping out the __init__ stuff into a
"config" module or something like that. The reason is that every time
someone wants to use matplotlib as a library, eg to import a single
function from matplotlib.cbook, they have to pay for the entire
__init__load including the rc parse, even though cbook doesn' use
anything else from the rest of matplotlib. It only depends on the
standard library. So there is at least one additional reason to move
the stuff from __init__ out. I also like the ability to use eggs to
have mpl namespace packages, eg toolkits.
So if ease-of-implementation is the only argument against ripping out
the __init__ stuff I don't find it compelling (I'll be happy to do it)
but if there are other reasons to leave __init__ as is let's hear
them.
JDH

I'll fess up that I added the setuptools namespace support for the
toolkits. Keep in mind I did this a LONG time ago, and as implied
below the docs were sketchy. It did work at the time, but I honestly
have not had basemap installed in a while to see the breakage.
Charlie
On 2/9/07, Andrew Straw <str...@as...> wrote:
> It looks like we're on the hook for some bugs associated with our use of
> setuptools... I'm forwarding an email from the distutils-sig.
>
> The short of it is that Phillip Eby suggests we move matplotlib.toolkits
> to matplotlib_toolkits to save ourselves some grief. This does seem
> easier than the apparent alternative -- moving everything out of
> matplotlib/__init__.py.
>
> -Andrew
>
>
> ---------- Forwarded message ----------
> From: "Phillip J. Eby" <pj...@te...>
> To: sk...@po..., dis...@py...
> Date: 2007年2月09日 19:20:31 -0500
> Subject: Re: [Distutils] Confusion about the effect of eggs on import
> At 05:30 PM 2/9/2007 -0600, sk...@po... wrote:
> >(I'm sending this to distutils because I have this vague notion that the
> >problem might have something to do with setuptools or eggs on sys.path.)
>
> Their mere presence on sys.path doesn't do anything, if you're not
> importing pkg_resources or importing anything from inside the eggs.
>
> However, matplotlib imports pkg_resources and is a (broken) namespace package.
>
>
> >We have a weird issue trying to import matplotlib at work.
>
> I investigated a little, and here's what's happening. Matplotlib declares
> 'matplotlib.toolkits' as a namespace package, but you can't make a child
> package a namespace package without the parent being one too. A namespace
> package combines all packages on sys.path with the same name into a single
> package.
>
> So here's what's happening. When setuptools is on sys.path, then importing
> matplotlib causes it to declare its namespace, which merges all copies of
> matplotlib on sys.path into a single super-package -- and invokes all the
> __init__.py's.
>
> When setuptools is not on sys.path, the attempt to declare the namespace
> fails (it's wrapped in a try/except in matplotlib/__init__.py), so nothing
> else happens.
>
> There are, I think, two problems here. One, is that setuptools shouldn't
> be executing multiple __init__.py's for a package, but for backward
> compatibility reasons this isn't being dropped until 0.7a1. Two, is that
> setuptools currently allows you to declare a child namespace package (like
> 'matplotlib.toolkits') without explicitly declaring the parent to be a
> namespace package. So, sometimes people declare a subpackage without
> realizing the parent will also have to be treated as a namespace package.
>
> As a result, they end up thinking that they can include initialization code
> in the parent package, when in fact there are many circumstances where it
> simply won't work. In this case, matplotlib/__init__.py contains
> executable code, which is a no-no for a namespace package.
>
> My suggestion would be that matplotlib use a matplotlib_toolkits namespace
> package, rather than attempting to keep matplotlib.toolkits, since it
> appears they are relying on a substantial amount of code living in the
> __init__.py.
>
> In short, the problem is a matplotlib bug, but in fairness it's probably
> due to the sketchy documentation surrounding the proper care and feeding of
> namespace packages, coupled with the implicit declaration of namespace
> packages. All of the problems are explained in the setuptools
> documentation, but unfortunately that's not the same as anybody being able
> to figure out that the problems will apply to THEM. ;)
>
> _______________________________________________
> Distutils-SIG maillist - Dis...@py...
> http://mail.python.org/mailman/listinfo/distutils-sig
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

It looks like we're on the hook for some bugs associated with our use of 
setuptools... I'm forwarding an email from the distutils-sig.
The short of it is that Phillip Eby suggests we move matplotlib.toolkits 
to matplotlib_toolkits to save ourselves some grief. This does seem 
easier than the apparent alternative -- moving everything out of 
matplotlib/__init__.py.
-Andrew

On 2/9/07, J=F6rgen Stenarson <jor...@bo...> wrote:
> the recent announcment of matplotlib 0.9 made me look through my notes
> on bugs I've found. With 0.87.7 pylab.axis does not support setting of
> axislimits, I have attached a crash report. I think the problem is a
> change in the handling of kwargs in set_*lim in axes.py.
Hmm, I find your post a little confusing. You mention that you notice
0.90 is out and yet you test on 0.87.7.... This bug was fixed in the
0.90 release. Do you not have access to 0.90 for some reason, ie you
need a binary that hasn't been built?

Hi
Saving a semilogy plot using the odf backend the exponents come out 
wrong. As can be seen in the attached png file pdf-backend.png the 
exponents are printed as a subscript and also with the lowest value at 
the top of the axis, 10e-3 is at the top and 10e3 is at the bottom. See 
t-pngbackend.png for the behaviour I get with a png backend.
Looking at the source for the pdf-backend I also saw that it contains a 
mix of space and tabs for indentation.
Keep up the good work, I'm looking forward to using 0.9 when the win32 
binary is out.
/Jörgen

hi
the recent announcment of matplotlib 0.9 made me look through my notes 
on bugs I've found. With 0.87.7 pylab.axis does not support setting of 
axislimits, I have attached a crash report. I think the problem is a 
change in the handling of kwargs in set_*lim in axes.py.
/Jörgen
In [1]: x=arange(0,pi,0.1)
In [2]: plot(x,sin(x))
Out[2]: [<matplotlib.lines.Line2D instance at 0x01BF6828>]
In [3]: axis(ymin=-1)
---------------------------------------------------------------------------
<type 'exceptions.TypeError'> Traceback (most recent call last)
C:\Python25\<ipython console> in <module>()
c:\Python25\lib\site-packages\matplotlib\pylab.py in axis(*v=(), 
**kwargs={'ymin': -1})
 622 """
 623 ax = gca()
--> 624 v = ax.axis(*v, **kwargs)
 v = ()
 ax.axis = <bound method Subplot.axis of 
<matplotlib.axes.Subplot instance at 0x01BEF1E8>>
 kwargs = {'ymin': -1}
 625 draw_if_interactive()
 626 return v
c:\Python25\lib\site-packages\matplotlib\axes.py in 
axis(self=<matplotlib.axes.Subplot instance at 0x01BEF1E8>, *v=(), 
**kwargs={'ymin': -1})
 774 try: v[0]
 775 except IndexError:
--> 776 xmin, xmax = self.set_xlim(**kwargs)
 xmin = undefined
 xmax = undefined
 self.set_xlim = <bound method Subplot.set_xlim of 
<matplotlib.axes.Subplot instance at 0x01BEF1E8>>
 kwargs = {'ymin': -1}
 777 ymin, ymax = self.set_ylim(**kwargs)
 778 return xmin, xmax, ymin, ymax
<type 'exceptions.TypeError'>: set_xlim() got an unexpected keyword 
argument 'ymin'
In [4]:

On 2/8/07, Eric Firing <ef...@ha...> wrote:
> Janesh Ramakrishnan wrote:
> I see what you mean; I imagine it is a problem with the auto-generated
> html, but I don't know what to do about it. Maybe someone else on the
> devel list knows the solution.
pydoc is generating links to the docs for the modules we are including
(eg sys) but we are not generating docs for those modules. It may be
enough to simply includfe and __all__ for the mpl modules so that
these symbols are not exported. Or there may be a simple flag for
pydoc to suppress this kind of thing. Off the top of my head, I don't
know..
JDH

Janesh Ramakrishnan wrote:
> Hi Eric,
> 
> The links seem to be broken on the matplotlib pages at sourceforge.net.
> 
> For example, if I'm on http://matplotlib.sourceforge.net/matplotlib.backend_bases.html
> 
> and if I click on the sys text (http://matplotlib.sourceforge.net/sys.html), a 404 error is caused. 
> 
> Same thing happens when I click warnings, matplotlib.widgets etc. 
> 
> Janesh
I see what you mean; I imagine it is a problem with the auto-generated 
html, but I don't know what to do about it. Maybe someone else on the 
devel list knows the solution.
Eric

On Wednesday 07 February 2007 12:09:18 pm Rob Hetland wrote:
> The MPL Qt backend requires PyQt (or, better, Qt4 and PyQt4). PyQt
> does compile against the Qt Library, and also takes quite a while to
> complete. PyQt does not use setuptools, and I am not sure how to
> make a generally usable binary distribution from it.
>
> I would say that installation is quite easy (although time consuming)
> -- perhaps just a good set of directions on the MPL site?
>
> -Rob
>
> On Feb 7, 2007, at 10:01 AM, Christopher Barker wrote:
> > Thanks for doing this Rob, its nice to get as much support on OS-X as
> > possible.
> >
> > Does the QT back-end need to be compiled against QT? or is it
> > python-only?
The Qt backend is pure python. 
Darren

The MPL Qt backend requires PyQt (or, better, Qt4 and PyQt4). PyQt 
does compile against the Qt Library, and also takes quite a while to 
complete. PyQt does not use setuptools, and I am not sure how to 
make a generally usable binary distribution from it.
I would say that installation is quite easy (although time consuming) 
-- perhaps just a good set of directions on the MPL site?
-Rob
On Feb 7, 2007, at 10:01 AM, Christopher Barker wrote:
> Thanks for doing this Rob, its nice to get as much support on OS-X as
> possible.
>
> Does the QT back-end need to be compiled against QT? or is it 
> python-only?
>
>> QT4 takes *forever* to compile, but it seems to compile easier now
>> than previous versions that needed a small library hack. The default
>> configuration compiles and installs fine. The other tools (PyQt4 and
>> SIP) also compile and install painlessly with the default 
>> configuration.
>
> Any chance you could package it up an submit it to the pythonmac 
> archive?
>
> Does it support a Universal build?
>
> -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...
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services, 
> security?
> Get stuff done quickly with pre-integrated technology to make your 
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

Werner F. Bruhin wrote:
> Great to see a new release, will put some time aside to test it with 
> wxPython early next week.
looking forward to your reports.
> which versions of wxPython are supported?
I haven't tried the new one, but the last release worked well with 
wxPython2.6.3, but had some issues with 2.8.* -- I don't think anyone 
has addressed those yet.
> Well, we haven't built any binaries yet. We pushed a source release
> fast to try to get it into Feisty. Sorry Chris!
well, I've been chattering on about this for awhile, but haven't 
contributed anything yet...
 > With wx2.8 out now
> and this being a major release, we definitely need to rethink wx
> builds. We stuck with unicode for 0.87 to avoid confusion. I would
> be happy to hear what wx users think/want.
I think it's time to just all unicode, all the way, but I mostly deal 
with English anyway.
> For me the ideal would be not to be depended on a particular release of 
> wxPython - big surprise no :-)
That would be nice.
> If I understand it correctly the dependency came in for performance 
> optimization, does 2.8 change something for this.
Perhaps. 2.8 has methods for directly setting the data in wxBitmaps. 
Before that, you needed to create a wxImage, then convert that to a bitmap.
However, to do that right, you'd need to be able to get the Agg bitmap 
as a Python buffer object that is in the binary form required by the 
platform. I think the majors need RGB and/or RGBA, but I'm not totally 
sure about that (maybe OS-X is ARGB?)
> - If yes, I would not see a problem with 0.9 requiring as a minimum 
> 2.8.0.1 but going forward I could use any 2.8.x or newer release.
That would be a good way to go, or have fallback on the older methods 
for less than 2.8 -- so instead of saying "you need 2.8 to use the wx 
backend" we can say: "you'll get better performance with wx if you use > 
2.8"
> - If no, then I guess we have to live with having a "fixed" dependency, 
> e.g. 0.87 is wxPython 2.6.x, 0.90 is wxPython 2.8.x, but it should 
> through at least a warning if one tries to use it with another wxPython 
> release.
Yes, it should. I've also started a patch for the build system that 
tries harder to make sure that you are building against the same wx that 
you are running -- that will at least help people built it themselves 
more easily.
NOTE: I took a look at the wx backend code a while ago, and it looks 
like even without the new Bitmap handlers in 2.8, it could be faster 
with straight Python code. Key is that a wxImage can be created from a 
Python buffer object without copying the data. So if we can expose the 
Agg buffer as a Python buffer, as RGB, then we should be able to get 
decent performance with pure python. You'd still need to do the 
wxBitmapFromImage thing, but the accelerated back-end does that too.
Look for a thread on this list a while back, with my and Ken's name on it.
-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...