matplotlib-users Mailing List for matplotlib

I don't know if everything 3D works, but the first error you note below 
is fixed in svn, and I suspect in 0.87.7, the last release. 0.87.5 is 
rather old--quite a bit has changed between minor releases.
Eric
Matthew Koichi Grimes wrote:
> contourf3D and contour3D seem to be broken in my copy of matplotlib 
> 0.87.5 that I installed from ubuntu edgy's repositories. Is this a known 
> problem? I started going through axes3d.py etc and fixing the reported 
> errors, but the error trail seems to go pretty deep across multiple 
> files. Now I'm wondering if maybe this is something major that has 
> already been fixed by more experienced hands in SVN or something.
> 
> In the off chance that this is an unknown problem, I've enumerated the 
> errors below. These all happened while attempting to run the example 
> code in http://www.scipy.org/Cookbook/Matplotlib/mplot3D
> 
> If it's fixed in SVN, I'll try installing that, but I haven't seen this 
> bug mentioned in matplotlib's bug list on sourceforge.net.
> 
> -- Matt
> 
> When I called contourf3D the first time, I got the following error:
> 
> <snip>
> File "/usr/lib/python2.4/site-packages/matplotlib/axes3d.py", line 596, 
> in contourf3D
> levels, colls = self.contourf(X, Y, Z, 20)
> TypeError: unpack non-sequence
> </snip>
> 
> As suggested in the examples page above, I went into contourf3D's 
> function definition in axes3d.py and replaced:
> 
> levels, colls = self.contourf(X, Y, Z, 20)
> 
> with
> 
> C = self.contourf(X, Y, Z, *args, **kwargs)
> levels, colls = (C.levels, C.collections)
> 
> I then got a new error when calling contourf3D:
> 
> <snip>
> exceptions.NameError Traceback (most 
> recent call last)
> 
> /home/mkg/Desktop/<ipython console>
> 
> /usr/lib/python2.4/site-packages/matplotlib/axes3d.py in 
> contourf3D(self, X, Y, Z, *args, **kwargs)
> 604 zs = [z1] * (len(linec._verts[0])/2)
> 605 zs += [z2] * (len(linec._verts[0])/2)
> --> 606 art3d.wrap_patch(linec, zs, fn=draw_polyc)
> 607 self.auto_scale_xyz(X,Y,Z, had_data)
> 608 return levels,colls
> 
> NameError: global name 'draw_polyc' is not defined
> </snip>
> 
> After changing draw_polyc to art3d.draw_polyc, it complained that 
> art3d.wrap_patch in fact only takes two arguments. So I changed
> 
> art3d.wrap_patch(linec, zs, fn=draw_polyc)
> 
> to
> 
> art3d.wrap_patch(linec, zs)
> 
> Which led to the latest error message:
> 
> <snip>
> Traceback (most recent call last):
> File 
> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", 
> line 284, in expose_event
> self._render_figure(self._pixmap, w, h)
> File 
> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py", 
> line 73, in _render_figure
> FigureCanvasAgg.draw(self)
> File 
> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py", 
> line 391, in draw
> self.figure.draw(renderer)
> File "/usr/lib/python2.4/site-packages/matplotlib/figure.py", line 
> 538, in draw
> for a in self.axes: a.draw(renderer)
> File "/usr/lib/python2.4/site-packages/matplotlib/axes3d.py", line 
> 172, in draw
> Axes.draw(self, renderer)
> File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1057, 
> in draw
> a.draw(renderer)
> File "/usr/lib/python2.4/site-packages/matplotlib/art3d.py", line 56, 
> in call_draw3d
> self.draw3d(renderer)
> File "/usr/lib/python2.4/site-packages/matplotlib/art3d.py", line 184, 
> in draw3d
> xs,ys = zip(*self._offsets)
> TypeError: zip() argument after * must be a sequence
> </snip>
> 
> Contour3D (not contourf3D) does work in that it successfully displays a 
> plot, but when I mouseover this plot, my python console fills with the 
> following error message (one repetition for each mouse event):
> 
> <snip>
> /usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py in 
> motion_notify_event(self, widget, event)
> 178 # flipy so y=0 is bottom of canvas
> 179 y = self.allocation.height - y
> --> 180 FigureCanvasBase.motion_notify_event(self, x, y)
> 181 return False # finish event propagation?
> 182
> 
> /usr/lib/python2.4/site-packages/matplotlib/backend_bases.py in 
> motion_notify_event(self, x, y, guiEvent)
> 885 event = MouseEvent('motion_notify_event', self, x, y, 
> self._button, self._key, guiEvent=guiEvent)
> 886 for func in self.callbacks.get('motion_notify_event', 
> {}).values():
> --> 887 func(event)
> 888
> 889 def draw(self, *args, **kwargs):
> 
> /usr/lib/python2.4/site-packages/matplotlib/axes3d.py in on_move(self, 
> event)
> 396 """
> 397 #NOTE - this shouldn't be called before the graph has 
> been drawn for the first time!
> --> 398 if event.inaxes != self or not self.M:
> 399 return
> 400 #
> 
> ValueError: The truth value of an array with more than one element is 
> ambiguous. Use a.any() or a.all()
> </snip>
> 
> 
> 
> 
> -------------------------------------------------------------------------
> 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

contourf3D and contour3D seem to be broken in my copy of matplotlib 
0.87.5 that I installed from ubuntu edgy's repositories. Is this a known 
problem? I started going through axes3d.py etc and fixing the reported 
errors, but the error trail seems to go pretty deep across multiple 
files. Now I'm wondering if maybe this is something major that has 
already been fixed by more experienced hands in SVN or something.
In the off chance that this is an unknown problem, I've enumerated the 
errors below. These all happened while attempting to run the example 
code in http://www.scipy.org/Cookbook/Matplotlib/mplot3D
If it's fixed in SVN, I'll try installing that, but I haven't seen this 
bug mentioned in matplotlib's bug list on sourceforge.net.
-- Matt
When I called contourf3D the first time, I got the following error:
<snip>
File "/usr/lib/python2.4/site-packages/matplotlib/axes3d.py", line 596, 
in contourf3D
 levels, colls = self.contourf(X, Y, Z, 20)
TypeError: unpack non-sequence
</snip>
As suggested in the examples page above, I went into contourf3D's 
function definition in axes3d.py and replaced:
 levels, colls = self.contourf(X, Y, Z, 20)
with
 C = self.contourf(X, Y, Z, *args, **kwargs)
 levels, colls = (C.levels, C.collections)
I then got a new error when calling contourf3D:
<snip>
exceptions.NameError Traceback (most 
recent call last)
/home/mkg/Desktop/<ipython console>
/usr/lib/python2.4/site-packages/matplotlib/axes3d.py in 
contourf3D(self, X, Y, Z, *args, **kwargs)
 604 zs = [z1] * (len(linec._verts[0])/2)
 605 zs += [z2] * (len(linec._verts[0])/2)
--> 606 art3d.wrap_patch(linec, zs, fn=draw_polyc)
 607 self.auto_scale_xyz(X,Y,Z, had_data)
 608 return levels,colls
NameError: global name 'draw_polyc' is not defined
</snip>
After changing draw_polyc to art3d.draw_polyc, it complained that 
art3d.wrap_patch in fact only takes two arguments. So I changed
 art3d.wrap_patch(linec, zs, fn=draw_polyc)
to
 art3d.wrap_patch(linec, zs)
Which led to the latest error message:
<snip>
Traceback (most recent call last):
 File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", 
line 284, in expose_event
 self._render_figure(self._pixmap, w, h)
 File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 73, in _render_figure
 FigureCanvasAgg.draw(self)
 File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py", 
line 391, in draw
 self.figure.draw(renderer)
 File "/usr/lib/python2.4/site-packages/matplotlib/figure.py", line 
538, in draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib/python2.4/site-packages/matplotlib/axes3d.py", line 
172, in draw
 Axes.draw(self, renderer)
 File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1057, 
in draw
 a.draw(renderer)
 File "/usr/lib/python2.4/site-packages/matplotlib/art3d.py", line 56, 
in call_draw3d
 self.draw3d(renderer)
 File "/usr/lib/python2.4/site-packages/matplotlib/art3d.py", line 184, 
in draw3d
 xs,ys = zip(*self._offsets)
TypeError: zip() argument after * must be a sequence
</snip>
Contour3D (not contourf3D) does work in that it successfully displays a 
plot, but when I mouseover this plot, my python console fills with the 
following error message (one repetition for each mouse event):
<snip>
/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py in 
motion_notify_event(self, widget, event)
 178 # flipy so y=0 is bottom of canvas
 179 y = self.allocation.height - y
--> 180 FigureCanvasBase.motion_notify_event(self, x, y)
 181 return False # finish event propagation?
 182
/usr/lib/python2.4/site-packages/matplotlib/backend_bases.py in 
motion_notify_event(self, x, y, guiEvent)
 885 event = MouseEvent('motion_notify_event', self, x, y, 
self._button, self._key, guiEvent=guiEvent)
 886 for func in self.callbacks.get('motion_notify_event', 
{}).values():
--> 887 func(event)
 888
 889 def draw(self, *args, **kwargs):
/usr/lib/python2.4/site-packages/matplotlib/axes3d.py in on_move(self, 
event)
 396 """
 397 #NOTE - this shouldn't be called before the graph has 
been drawn for the first time!
--> 398 if event.inaxes != self or not self.M:
 399 return
 400 #
ValueError: The truth value of an array with more than one element is 
ambiguous. Use a.any() or a.all()
</snip>

Dear all,
I am coming back to an issue for which I didn't get a direct answer
(except for a very nice module from Angus McMorland!):
- at the moment different backends in mpl automatically provides, when
an image (or a plot) is displayed with e.g. imshow (plot), the
coordinates x and y directly in the toolbar.
- When it is indeed an image wich is displayed, it would, in my opinion
makes a LOT of sense to also display the "z" coordinate, namely the
'intensity' value of the pixel of the image on which the cursor is
standing.
The questions are then: does this also make sense to you, and if yes,
would it be possible for someone to implement it as an intrinsic feature
of mpl backends? (I am not competent to answer the feasibility part
here, although the module Angus nicely provided on the list is an
excellent example, even if it adds one more layer which may be avoidable).
thanks for any input here!
cheers
Eric

Hi all
I am trying to plot the trajectory of the Lorenz system with the axes3d.py
module (version 0.87.7). The code is the following:
from numpy import *
from scipy.integrate import odeint
import pylab as p
import matplotlib.axes3d as p3
def Lorenz(w, t, s, r, b):
 x, y, z = w
 return array([s*(y-x), r*x-y-x*z, x*y-b*z])
# Parameters
s = 8.0
r = 28.1
b = 8/3.0
w_0 = array([0., 0.8, 0.]) # Initial condition
time = arange(0., 100., 0.01) # time vector
trajectory = odeint(Lorenz, w_0, time, args=(s, r, b)) # 10^5 x 3 array
# There must be better ways to do this:
x = trajectory[:,0]
y = trajectory[:,1]
z = trajectory[:,2]
# 3D plotting
fig=p.figure()
ax = p3.Axes3D(fig)
ax.plot3D(x,y,z) # I guess this is the method to use
p.show()
I get however some errors related with the autoscale_view() method (see below).
I have two questions: Is plot3D the correct choice for plotting a 3D
curve? In that case, is there any way to fix these errors?
Thanks a lot for your help and for making matplotlib possible,
dani
Errors (pdb output):
lorenz.py
---> 42 plot3D(x,y,z)
/usr/lib/python2.4/site-packages/matplotlib/axes3d.py in plot3D(self,
xs, ys, zs, *args, **kwargs)
 488 def plot3D(self, xs, ys, zs, *args, **kwargs):
 489 had_data = self.has_data()
--> 490 lines = Axes.plot(self, xs,ys, *args, **kwargs)
 491 if len(lines)==1:
 492 line = lines[0]
/usr/lib/python2.4/site-packages/matplotlib/axes.py in plot(self,
*args, **kwargs)
 2129 lines = [line for line in lines] # consume the generator
 2130
-> 2131 self.autoscale_view(scalex=scalex, scaley=scaley)
 2132 return lines
TypeError: autoscale_view() got an unexpected keyword argument 'scalex'
> /usr/lib/python2.4/site-packages/matplotlib/axes.py(2131)plot()
 2130
-> 2131 self.autoscale_view(scalex=scalex, scaley=scaley)
 2132 return lines

Hi,
I am a newbie in matplotlib. I want to use the following label (in latex)
\langle \partial_x U(x) \rangle.
When i use
 ylabel(r"$\langle \partial_x U(x) \rangle$",fontsize=30);
matplotlib complains by saying 
 Traceback (most recent call last):
 File
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_gtk.py", line
277, in expose_event
 self._render_figure(width, height)
 File
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_gtkagg.py",
line 91, in _render_figure
 FigureCanvasAgg.draw(self)
 File
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_agg.py", line
369, in draw
 self.figure.draw(renderer)
 File "/usr/lib/python2.3/site-packages/matplotlib/figure.py", line 498, in
draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 1362, in
draw
 self.yaxis.draw(renderer)
 File "/usr/lib/python2.3/site-packages/matplotlib/axis.py", line 578, in
draw
 self.label.draw(renderer) # memory leak here, vertical text
 File "/usr/lib/python2.3/site-packages/matplotlib/text.py", line 334, in
draw
 bbox, info = self._get_layout(renderer)
 File "/usr/lib/python2.3/site-packages/matplotlib/text.py", line 179, in
_get_layout
 w,h = renderer.get_text_width_height(
 File
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_agg.py", line
242, in get_text_width_height
 width, height, fonts = math_parse_s_ft2font(
 File "/usr/lib/python2.3/site-packages/matplotlib/mathtext.py", line 1222,
in math_parse_s_ft2font
 handler.expr.set_size_info(fontsize, dpi)
 File "/usr/lib/python2.3/site-packages/matplotlib/mathtext.py", line 870,
in set_size_info
 self.elements[0].set_size_info(self._scale*fontsize, dpi)
 File "/usr/lib/python2.3/site-packages/matplotlib/mathtext.py", line 795,
in set_size_info
 Element.set_size_info(self, fontsize, dpi)
 File "/usr/lib/python2.3/site-packages/matplotlib/mathtext.py", line 708,
in set_size_info
 element.set_size_info(self.fontsize, dpi)
 File "/usr/lib/python2.3/site-packages/matplotlib/mathtext.py", line 796,
in set_size_info
 self.metrics = Element.fonts.get_metrics(
 File "/usr/lib/python2.3/site-packages/matplotlib/mathtext.py", line 409,
in get_metrics
 cmfont, metrics, glyph, offset = \
 File "/usr/lib/python2.3/site-packages/matplotlib/mathtext.py", line 429,
in _get_info
 raise ValueError('unrecognized symbol "%s"' % sym)
ValueError: unrecognized symbol "\partial"
 I searched the forum for something similar and could not find anything.
Also my latex can typeset the above if i run it in a separate tex file. I
am using the GTKAgg backend.
Could someone please help me out?
Bye
Vijay
-- 
View this message in context: http://www.nabble.com/Latex-%5Cpartial-tf2963980.html#a8292755
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hi,
> With the exception of ipython -pylab, noone is forcing you to import
> *. And on the subject, Fernando, perhaps we should support a pylab
> mode in ipython which doesn't dump the pylab namespace (or maybe just
> dumps the required figure, show, close, nx), but does the interactive
> backend stuff.
In the meantime, I did the following to my local dev copy of IPython: 
Instead of the existing "import..." viq exec into user namespace, I do:
import pylab as P
import numpy as N
import matplotlib as M
It would be nice if controlling this type of thing was configurable.
--b

>>>>> "Christopher" == Christopher Barker <Chr...@no...> writes:
 Christopher> F1 = OOlab.Figure() F2 = OOlab.Figure()
We have this:
 
 fig1 = pylab.figure()
 fig2 = pylab.figure()
 ax1 = fig.add_subplot(111)
 line, = ax1.plot([1,2,3])
 line.set_color('green')
 ax1.set_title('hi mom')
Yes, it would be nice to be able to do
 ax1.title = 'hi mom'
but other than that pretty much everything you describe already
exists. 
Instead of thinking about OOlab, which mostly already exists, I think
it's more useful to focus on a few shortcuts which will make OO use as
easy as pylab. It is already -- I pretty much use the OO interface
exclusively in all my work. All my scripts start with
 from pylab import figure, close, show, nx
and that's all, and it works fine.
One helpful tip: the children point to their parents, so expanding on
Jeff's point about the line containing a pointer to the axes it lives
in, you can also reference the figure and canvas as upstream
containers
 line.axes.figure.canvas.draw()
for example.
 Christopher> Why couldn't plot(x,y) create and return a figure
 Christopher> object? Or an axis object? -- I haven't thought it
 Christopher> out too much yet.
Because it returns a line object. But I do think it is a design
limitation to plot make an axes method.
 >> For interactive use, I really don't see any advantage to an OO
 Christopher> interface.
 Christopher> Well, for *just* interactive use, I agree, but I see
 Christopher> some very large advantages to an OO style for
 Christopher> embedding in programs and larger projects. 
Sure, all programmers agree with that. For scripts and apps, the OO
interface is clearly superior. Teachers teaching students who are new
to programming, however, are adamant that the pylab/proceedural
interface is crucial to get them to adopt python over matlab, and I
trust them. And for interactive quick-and-dirty minimize-the-typing
work, the current figure, current axes approach is quite handy.
 Christopher> As handy as it is to have a command line to play
 Christopher> with, if I'm writing more than four or five lines
 Christopher> (and I usually am!), I'm happier putting them in a
 Christopher> file and running them as a script. Even in that case,
 Christopher> I don't mind a little extra typing.
 Christopher> What I'm envisioning for "OOlab" is a set of utility
 Christopher> functions that do make some of the pylab stuff easy
 Christopher> -- not well thought out yet, but something like:
It's all there with the exception of GUI window management, and you
might as well use pylab for that. That saves you a lot of
boilerplate.
 Christopher> F = ooLab.figure(1) # I often need to plot more than
 Christopher> one figure anyway, so I don't mind having to type
 Christopher> that.
 Christopher> ax = F.plot(x,y) # there could be this and subplot
Well, this breaks the whole concept of multiple axes, though one could
have a helper function that assumes subplot(111) ... But explicit is
better than implicit so may as well instantiate the Axes with
fig.add_subplot...
 Christopher> ax.set_title = "A title for the plot" # or better
 Christopher> yet: ax.title = "A title for the plot" # I'd like to
 Christopher> see more properties in MPL too!
Agreed.
 Christopher> ax.grid(True) . . .
Exists...
 Christopher> Note that some of this comes from my love of
 Christopher> namespaces -- I really don't like "import*" -- the
 Christopher> way that can work is using more OO, so you don't need
 Christopher> to type the module name everywhere.
With the exception of ipython -pylab, noone is forcing you to import
*. And on the subject, Fernando, perhaps we should support a pylab
mode in ipython which doesn't dump the pylab namespace (or maybe just
dumps the required figure, show, close, nx), but does the interactive
backend stuff.
 Christopher> I don't see much advantage to keeping the idea of a
 Christopher> "current figure" or "current axis" -- it's just not
 Christopher> that hard to keep a reference. Maybe it does help for
 Christopher> quickie command line stuff, but I think for even
 Christopher> quickie scripts, it's clearer to name your axes, etc.
Agreed. I should rewrite all the examples and move the existing
examples into a "matlab-like" dir. The examples would all start with
the minimal import of figure, show, nx and close.
 Christopher> However, the proof is in the pudding -- what needs to
 Christopher> be done is for someone to sit down and start using
 Christopher> MPL in interactive/quickie script use without pylab,
 Christopher> and write something for OOlab whenever something is
 Christopher> harder to do than it should be. Then we'll see how it
 Christopher> works out.
No, one should just use pylab for figure creation and destruction and
add convenience methods to shorten some calls if needed, just as we
did when we added fig.savefig as a shorthad for
fig.canvas.print_figure on your suggestion. We don't need a new
interface though we could improve the existing one to handle some
annoyances. We do, however, want to use properties in the existing
interface.
Note also for the interactive use, we could probably utilize ipython
to call draw in special hooks.
Fernando: if one does
 In[5]: o.set_something(blah)
can we configure ipython to do
 gcf().canvas.draw()
iff o is an instance of a matplotlib.Artist?
JDH

FWIW
On Jan 11, 2007, at 5:29 PM, Bob Ippolito wrote:
> On 1/11/07, Nicholas Riley <nj...@ui...> wrote:
>> On Thu, Jan 11, 2007 at 02:21:19PM -0800, Christopher Barker wrote:
>>> Is it that hard to make a binary to put up (OK, two - one for 
>>> PPC, one
>>> for Intel), once you've gotten it all built? At least a few 
>>> people have
>>> gotten it going recently. Could someone please make them available?
>>
>> How about posting them on your own Web site then? If you don't have
>> one, the price of commodity Web hosting is virtually zero, and there
>> are plenty of free open source project hosting services around, some
>> of them even good.
>>
>> It's been repeatedly stated on this mailing list that the currently
>> pythonmac.org maintainer doesn't have time, and would be happy to
>> relinquish control to someone who did. But nobody's volunteered.
>>
>> It is really rather tiresome to read about people asking for 
>> "someone"
>> to do something when everyone's doing this work for free.
>>
>
> Well I'm back in the country now and I just got my mbp back from
> applecare today... so if "someone" sends me updated binaries I'll
> gladly sync them to pythonmac.org.
>
> -bob

> PPS: Belinda, now that you've done all this work, I do hope you can 
> go the extra mile and figure out how to make a binary package of it 
> all for others!
I certainly would like to to do this, but its gonna have to wait 
until after TheCurrentCrisis alleviates. Hopefully before Feb (in the 
worst case, mid-June), as I too am annoyed at how hard this seemed to 
be for the Mac. I also find it disconcerting that Vincent had 
different troubles than I w/the same source instructions (did they 
ever get resolved)? As had Erin.
At the same time, until about May I'll have access to both Intel and 
PPC Macs, so I have an ideal env. on which to test. I have only a 
vague idea how to make dmgs (have perused the incomprehensible 
hdutils man page), though, so may need some help. At the same time, 
I'm not qualified to fix the Vincent/Erin problems and have no idea 
how to go about making "universals" that work for everyone. In fact, 
these current threads lead me to wonder if it can actually be done 
(the sad alternative is this: anyone w/a Mac that wants to use the 
matscinum suite [defined below], unless you have piles of time to 
waste, stick w/matlab provided you can afford it). W/all this talk 
about numpy integrating w/python (via a PEP), it seems the best 
customers for such a move would be a unified matscinum community. 
Right now that community (at least on the Mac) is accessible to the 
uber-gang only (of which I barely pass the bar, but since I've gotten 
SOMETHING working, w/much online help, I feel I've earned the right 
to include myself).
I should mention a friend of mine who knows a lot more about sys 
stuff than I do had a heck of a time getting all this running on 
Linux---the entire package: matplotlib, numpy, scipy---lets call it 
the matscinum suite. In fact, it really seems this integration/ 
installation issue should be addressed across these 3 respective 
mailing lists, for if one doesn't work, the others become unusable 
for on non-trivial number of people (Perhaps there should be a list 
that is a combo of these three?)
FWIW, this is just hot off the macpython sig list:
---------
> Is it that hard to make a binary to put up (OK, two - one for PPC, one
> for Intel), once you've gotten it all built? At least a few people 
> have
> gotten it going recently. Could someone please make them available?
>
How about posting them on your own Web site then? If you don't have
one, the price of commodity Web hosting is virtually zero, and there
are plenty of free open source project hosting services around, some
of them even good.
It's been repeatedly stated on this mailing list that the currently
pythonmac.org maintainer doesn't have time, and would be happy to
relinquish control to someone who did. But nobody's volunteered.
It is really rather tiresome to read about people asking for "someone"
to do something when everyone's doing this work for free.
---------
I agree with the sentiments but also recognize that the documentation 
at scipy (where most of this stuff is loaded) is inaccurate, e.g. the 
superpak doesn't work.
Well, that's it for now. I'll try your wx rec's as soon as I find the 
time (likely next week).
Gotta run and thanks for all the help,
--b

so use pylab.gca() ?
On Jan 11, 2007, at 3:31 PM, Christopher Barker wrote:
> Jeff Whitaker wrote:
>
>> Chris: In the pylab interface, figure() returns a figure instance 
>> and
>> plot(x,y) returns a list of Line2d instances.
>
> yes, but it's the axis instance that you are most likely to need!
>
> - 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...
>
> ---------------------------------------------------------------------- 
> ---
> 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