matplotlib-devel Mailing List for matplotlib (Page 473)

Robert Hetland wrote:
> 
> On May 15, 2006, at 2:32 PM, Eric Firing wrote:
> 
>> there is a lengthy chunk of docstring explaining that if you expect 
>> x,y to be row,column, you are wrong!
>>
> 
> I think that most people who have used matlab, netcdf, etc. expect 
> things to be 'backwards,' like C instead 'forwards' like fortran.  I 
> always use a convention like var[time, z, y, x] which seems to work 
> nicely with things like sum and mean (which operate on the first axis by 
> default for time integrals and averages), with broadcast arrays (for 
> multiplying by dx and dy, which for me are typically only functions of x 
> and y), and, of course, with pcolor!
> 
> Should this way of thinking be put into an example?  Into the MPL 
> documentation?  Or, just let people figure it out naturally?

Rob,

Sounds to me like something you might want to put on one of the wikis.

I have tended not to think of the x,y order in terms of storage order; I 
just naturally think of coordinates as x,y,z, and indices as i,j,k, and 
so it seems natural for x to correspond to i, etc.  This is math 
notation, not computer science.  I suspect this is the same thing that 
trips up other people encountering the x-is-column-number convention in 
pcolor, hence the need for documentation, and possibly a friendly option 
for specifying the intended order.  I also suspect that the reason 
Matlab uses its present convention has nothing to do with storage 
order--Matlab started out in Fortran, and uses Fortran conventions--but 
rather with the way a matrix is written, with the second index 
increasing across the page from left to right.

Eric

I'm trying to change the fontsize of a legend:

from pylab import *
plot([1,2],[1,2],[1,2],[2,3])
l=legend()
# this doesnt work:
l.fontsize=20
draw()
# I think this should change the fontsize of the 
# first legend entry, but it changes both of them:
t=l.get_texts()
t[0].set_fontsize(20)

Also, is it possible to modify the layout of the legend entries, like the 
spacing between them (l.pad only changes the space between the entries and 
the frame) and the orientation (horizontal instead of vertical, or perhaps a 
table layout)?

I'm using svn-2398.

Thanks,
Darren

On May 15, 2006, at 2:32 PM, Eric Firing wrote:

> there is a lengthy chunk of docstring explaining that if you expect  
> x,y to be row,column, you are wrong!

I think that most people who have used matlab, netcdf, etc. expect  
things to be 'backwards,' like C instead 'forwards' like fortran.  I  
always use a convention like var[time, z, y, x] which seems to work  
nicely with things like sum and mean (which operate on the first axis  
by default for time integrals and averages), with broadcast arrays  
(for multiplying by dx and dy, which for me are typically only  
functions of x and y), and, of course, with pcolor!

Should this way of thinking be put into an example?  Into the MPL  
documentation?  Or, just let people figure it out naturally?

-Rob

-----
Rob Hetland, Assistant Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: he...@ta..., w: http://pong.tamu.edu

Rob,

I agree, what you propose is logical and desirable.  I think the 
implementation would be essentially a matter of using meshgrid 
internally when needed, or a piece of meshgrid for your single-vector 
case.  I don't think there will be any more efficient way to do it at 
present.  In the future, when we have only numpy to deal with, and when 
we are doing a grand unification of pcolor-like plotting methods, then 
perhaps things can be arranged so that even internally the x and y don't 
have to be expanded out.

In the meantime, I can try to make a simple version of this, while 
factoring common functionality out of pcolor and pcolormesh.

A related idea that I might want to try at the same time is a kwarg to 
control the orientation, so that x,y can correspond to row, column; as 
it is, there is a lengthy chunk of docstring explaining that if you 
expect x,y to be row,column, you are wrong!

John,

Can we simply remove pcolor_classic now?  Or are there circumstances 
under which it is still needed?

Eric

Robert Hetland wrote:
> 
> 
> I would like to propose expanding the inputs of pcolor to take  
> vectors.  Often, you have x and y independent (seperable), and you  
> don't want to go on constructing an x array of redundant values.   
> Actually, in NumPy it is not straightforward to do this with resize  if 
> your variable is in the first dimension like time.  This is  because 
> NumPy makes heavy use of array broadcasting, so that you  don't need to 
> drag around all that redundant data.
> 
> I realize that there is meshgrid, but I only use it for plotting  
> (because of array broadcasting), and only with two vectors (see the  
> second example below).  I think MPL would benifit from following the  
> spirit of array broadcasting, and make it such that:
> 
> x = arange(10)
> y = arange(30)
> z = rand(30,10)
> pcolor (x, y, z)
> 
> will work as expected.  Perhaps, we could require a NewAxis in the  
> right places, but it would also make sense without. We could also  
> consider the case of just one vector.  Consider
> 
> x,y = meshgrid(arange(10), arange(30))
> y = y + random.normal(size=y.shape)
> z = random.random(y.shape)
> pcolor (x, y, z)
> # but x is still essentially just arange(10), so it would be nice if  
> this worked, too.
> pcolor(arange(10), y, z)
> 
> What do you all think?
> 
> -Rob.
> 
> -----
> Rob Hetland, Assistant Professor
> Dept of Oceanography, Texas A&M University
> p: 979-458-0096, f: 979-845-6331
> e: he...@ta..., w: http://pong.tamu.edu
> 

I would like to propose expanding the inputs of pcolor to take  
vectors.  Often, you have x and y independent (seperable), and you  
don't want to go on constructing an x array of redundant values.   
Actually, in NumPy it is not straightforward to do this with resize  
if your variable is in the first dimension like time.  This is  
because NumPy makes heavy use of array broadcasting, so that you  
don't need to drag around all that redundant data.

I realize that there is meshgrid, but I only use it for plotting  
(because of array broadcasting), and only with two vectors (see the  
second example below).  I think MPL would benifit from following the  
spirit of array broadcasting, and make it such that:

x = arange(10)
y = arange(30)
z = rand(30,10)
pcolor (x, y, z)

will work as expected.  Perhaps, we could require a NewAxis in the  
right places, but it would also make sense without. We could also  
consider the case of just one vector.  Consider

x,y = meshgrid(arange(10), arange(30))
y = y + random.normal(size=y.shape)
z = random.random(y.shape)
pcolor (x, y, z)
# but x is still essentially just arange(10), so it would be nice if  
this worked, too.
pcolor(arange(10), y, z)

What do you all think?

-Rob.

-----
Rob Hetland, Assistant Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: he...@ta..., w: http://pong.tamu.edu

Eric Firing wrote:
> Jeff,
>
>
>> Playing around with it a bit with I found that using a format string 
>> in the format keyword causes an exception:
> ...
>>
>> Changing 'FormatStringFormatter' to 'FormatStrFormatter' in 
>> colorbar.py seems to fix it.
>
> Fixed, thanks.  I thought I had tested that, but...
>
>>
>> Also, the docs suggest that the ticks keyword can be a list, but if I 
>> use for example
>>
>> colorbar(ticks=[-1.0,0,1.0])
>>
>> I don't get what I expect.  In fact, it seems to use the default tick 
>> locations no matter what assign to ticks (a list or a ticker object, 
>> such as MultipleLocator(4)).  Am I mis-interpreting the docstrings?
>
> It was working as you expected for images but not for contours.  Now 
> that is fixed also.
>
> Eric
Excellent, thanks Eric!

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

Jeff,


> Playing around with it a bit with I found that using a format string in 
> the format keyword causes an exception:
...
> 
> Changing 'FormatStringFormatter' to 'FormatStrFormatter' in colorbar.py 
> seems to fix it.

Fixed, thanks.  I thought I had tested that, but...

> 
> Also, the docs suggest that the ticks keyword can be a list, but if I 
> use for example
> 
> colorbar(ticks=[-1.0,0,1.0])
> 
> I don't get what I expect.  In fact, it seems to use the default tick 
> locations no matter what assign to ticks (a list or a ticker object, 
> such as MultipleLocator(4)).  Am I mis-interpreting the docstrings?

It was working as you expected for images but not for contours.  Now 
that is fixed also.

Eric

Eric Firing wrote:
> I made a few modifications to the new colorbar, so part of my previous 
> message no longer applies.  If the new colorbar finds kwargs from 
> colorbar_classic, it issues a warning and then proceeds to call 
> colorbar_classic.  This should keep most old code working as before.
>
> Eric
>

Eric:  Thanks for all your hard work!  Looks like it should make 
colorbar much more flexible (and useful). 

Playing around with it a bit with I found that using a format string in 
the format keyword causes an exception:

Traceback (most recent call last):
  File "colorbar_test.py", line 10, in ?
    colorbar(format='%5.2f')
  File "/Users/jsw/lib/python/matplotlib/pylab.py", line 341, in colorbar
    ret = gcf().colorbar(mappable, cax = cax, **kw)
  File "/Users/jsw/lib/python/matplotlib/figure.py", line 676, in colorbar
    cb = cbar.Colorbar(cax, mappable, **kw)
  File "/Users/jsw/lib/python/matplotlib/colorbar.py", line 419, in __init__
    ColorbarBase.__init__(self, ax, **kw)
  File "/Users/jsw/lib/python/matplotlib/colorbar.py", line 125, in __init__
    self.formatter = ticker.FormatStringFormatter(format)
AttributeError: 'module' object has no attribute 'FormatStringFormatter


Changing 'FormatStringFormatter' to 'FormatStrFormatter' in colorbar.py 
seems to fix it.

Also, the docs suggest that the ticks keyword can be a list, but if I 
use for example

colorbar(ticks=[-1.0,0,1.0])

I don't get what I expect.  In fact, it seems to use the default tick 
locations no matter what assign to ticks (a list or a ticker object, 
such as MultipleLocator(4)).  Am I mis-interpreting the docstrings?

-Jeff


-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
325 Broadway                Boulder, CO, USA 80305-3328

I made a few modifications to the new colorbar, so part of my previous 
message no longer applies.  If the new colorbar finds kwargs from 
colorbar_classic, it issues a warning and then proceeds to call 
colorbar_classic.  This should keep most old code working as before.

Eric

All,

I have committed a new set of colorbar code, mainly in its own file 
(colorbar.py), and renamed the originals to pylab.colorbar_classic and 
figure.colorbar_classic.  All examples using colorbars that I could test 
have been modified if necessary, so that they work with the new version.

For a quick introduction, try contour_demo, contourf_demo, and image_masked.

The kwargs for the new version are quite different from the old, so this 
will cause breakage.  There are several possible ways of dealing with 
this, including using rc to simply specify which version of the colorbar 
is used.  I would prefer to avoid adding compatibility stuff directly to 
the new colorbar.

I think that the new colorbar has enough advantages over the old one to 
justify complete replacement as a goal.

Eric

Michael,

I think this is fixed as part of a large set of changes that I just 
committed to svn.

Eric

MICHAEL P MOSSEY wrote:
> The following script demonstrates a problem in autoscaling. Not all the data
> ends up in the window, when using set_aspect( aspect='equal',
> adjustable='datalim' ). This is using the cvs version as of a few weeks ago.
> 
> Note: This uses a closed polygon as data. The type of shape which triggers the
> bug is an asymmetical one (not symmetrical in x or y axes that is). Data which
> is symmetrical in x and y axes does not trigger the bug.
> 
> If you have questions, please copy me on reply, as I get the digest.
> 
> 
> import pylab
> 
> fig = pylab.figure( figsize = [ 8, 5 ] )
> axes = fig.add_axes( [ 0.1, 0.1, 0.8, 0.8 ] )
> axes.set_aspect( aspect='equal', adjustable='datalim' )
> 
> xs = [5.4, -6.3, -9.3, 0.5, 9.6, 5.4 ]
> ys = [8.4, 7.7, -3.6, -9.9, -2.5, 8.4 ]
> 
> axes.plot( xs, ys )
> 
> pylab.savefig( 'figure.png' )
> 
> 
> 
> 
> -------------------------------------------------------
> 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

I have confirmed the problem with current svn; I will work on it.

Eric

MICHAEL P MOSSEY wrote:
> The following script demonstrates a problem in autoscaling. Not all the data
> ends up in the window, when using set_aspect( aspect='equal',
> adjustable='datalim' ). This is using the cvs version as of a few weeks ago.
> 
> Note: This uses a closed polygon as data. The type of shape which triggers the
> bug is an asymmetical one (not symmetrical in x or y axes that is). Data which
> is symmetrical in x and y axes does not trigger the bug.
> 
> If you have questions, please copy me on reply, as I get the digest.
> 
> 
> import pylab
> 
> fig = pylab.figure( figsize = [ 8, 5 ] )
> axes = fig.add_axes( [ 0.1, 0.1, 0.8, 0.8 ] )
> axes.set_aspect( aspect='equal', adjustable='datalim' )
> 
> xs = [5.4, -6.3, -9.3, 0.5, 9.6, 5.4 ]
> ys = [8.4, 7.7, -3.6, -9.9, -2.5, 8.4 ]
> 
> axes.plot( xs, ys )
> 
> pylab.savefig( 'figure.png' )
> 
> 
> 
> 
> -------------------------------------------------------
> 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

The version I'm using is:

__version__  = '0.88'
__revision__ = '$Revision: 2251 $'
__date__     = '$Date: 2006-04-03 07:57:51 -0700 (Mon, 03 Apr 2006) $'

The following script demonstrates a problem in autoscaling. Not all the data
ends up in the window, when using set_aspect( aspect='equal',
adjustable='datalim' ). This is using the cvs version as of a few weeks ago.

Note: This uses a closed polygon as data. The type of shape which triggers the
bug is an asymmetical one (not symmetrical in x or y axes that is). Data which
is symmetrical in x and y axes does not trigger the bug.

If you have questions, please copy me on reply, as I get the digest.


import pylab

fig = pylab.figure( figsize = [ 8, 5 ] )
axes = fig.add_axes( [ 0.1, 0.1, 0.8, 0.8 ] )
axes.set_aspect( aspect='equal', adjustable='datalim' )

xs = [5.4, -6.3, -9.3, 0.5, 9.6, 5.4 ]
ys = [8.4, 7.7, -3.6, -9.9, -2.5, 8.4 ]

axes.plot( xs, ys )

pylab.savefig( 'figure.png' )

Jeff Whitaker wrote:
> Jordan Dawe wrote:
>> Hi, I just wanted to thank the devs for all the work they've done.  I 
>> just got my second journal article published, and all the figures 
>> were generated using matplotlib.  I put a note in the 
>> acknowledgements to that effect, for some cheap advertising.
>>
>> Here's a link to the pdf if you're interested, but you (or your U) 
>> needs a Geophysical Research Letters subscription to access it.
>>
>> http://www.agu.org/journals/gl/gl0609/2006GL025784/2006GL025784.pdf
>>
>> Thanks again.
>>
>> Jordan
>>
> Thanks for that, Jordan.  Nice job.  I'm curious, did you use basemap 
> for the maps? 
> -Jeff
>
No, I just did a contourf of the model's 'land' field.

Jordan

Jordan Dawe wrote:
> Hi, I just wanted to thank the devs for all the work they've done.  I 
> just got my second journal article published, and all the figures were 
> generated using matplotlib.  I put a note in the acknowledgements to 
> that effect, for some cheap advertising.
>
> Here's a link to the pdf if you're interested, but you (or your U) 
> needs a Geophysical Research Letters subscription to access it.
>
> http://www.agu.org/journals/gl/gl0609/2006GL025784/2006GL025784.pdf
>
> Thanks again.
>
> Jordan
>
Thanks for that, Jordan.  Nice job.  I'm curious, did you use basemap for the maps?  

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

Hi, I just wanted to thank the devs for all the work they've done.  I 
just got my second journal article published, and all the figures were 
generated using matplotlib.  I put a note in the acknowledgements to 
that effect, for some cheap advertising.

Here's a link to the pdf if you're interested, but you (or your U) needs 
a Geophysical Research Letters subscription to access it.

http://www.agu.org/journals/gl/gl0609/2006GL025784/2006GL025784.pdf

Thanks again.

Jordan

Oops, no idea this was already implemented.
I recalled discussion about the topic from way back I guess.
I'll give it a shot.
To get back to the real topic: it would indeed be even nicer if we didn't
have to convert to rgba.

On 5/10/06, Eric Firing <ef...@ha...> wrote:
>
> John Hunter wrote:
> >>>>>>"Mark" =3D=3D Mark Bakker <ma...@gm...> writes:
> >
> >
> >     Mark> Eric - If you are going to make changes here, would it be
> >     Mark> possible to pass a sequence of colors, one for each line
> >     Mark> segment in the collection.  You can check, for example,
> >     Mark> whether the length of the sequence is equal to the number of
> >     Mark> segments.  Would be very helpful for some people, as I have
> >     Mark> seen requests for this possibility several times on the
> >     Mark> list.
> >
> > Unless, I am misunderstanding you, you can already do that.  For
> > example, this is what scatter and polor do to make each element of the
> > collection a different color.
> >
> > Eric is talking about a convenience function so that you can pass
> > arbitrary colors arguments rather than rgba, ie the equivalent of
> >
> >   from matplotlib.colors import colorConverter
> >   colors =3D [colorConverter.to_rgba(x) for x in 'yellow', 0.5, (1,0,0,=
0.5
> )]
> >
> > you can then pass colors to a collection with three elements and get
> > the three colors yellow, gray and transparent red
>
> Exactly.  The convenience function already exists--it is
> Collection._get_color()--and it is already used in all the
> set_facecolor() and similar methods, but not in processing the
> initializer argument list.  What I have in mind is simply using it at
> initialization time.  I have not thought it through carefully yet,
> though; it is just something that came up while working on a new
> colorbar, and for the moment I am concentrating on the latter.
>
> Eric
>
>
>

John Hunter wrote:
>>>>>>"Mark" == Mark Bakker <ma...@gm...> writes:
> 
> 
>     Mark> Eric - If you are going to make changes here, would it be
>     Mark> possible to pass a sequence of colors, one for each line
>     Mark> segment in the collection.  You can check, for example,
>     Mark> whether the length of the sequence is equal to the number of
>     Mark> segments.  Would be very helpful for some people, as I have
>     Mark> seen requests for this possibility several times on the
>     Mark> list.
> 
> Unless, I am misunderstanding you, you can already do that.  For
> example, this is what scatter and polor do to make each element of the
> collection a different color.
> 
> Eric is talking about a convenience function so that you can pass
> arbitrary colors arguments rather than rgba, ie the equivalent of
> 
>   from matplotlib.colors import colorConverter
>   colors = [colorConverter.to_rgba(x) for x in 'yellow', 0.5, (1,0,0,0.5)]
> 
> you can then pass colors to a collection with three elements and get
> the three colors yellow, gray and transparent red

Exactly.  The convenience function already exists--it is 
Collection._get_color()--and it is already used in all the 
set_facecolor() and similar methods, but not in processing the 
initializer argument list.  What I have in mind is simply using it at 
initialization time.  I have not thought it through carefully yet, 
though; it is just something that came up while working on a new 
colorbar, and for the moment I am concentrating on the latter.

Eric

>>>>> "Mark" == Mark Bakker <ma...@gm...> writes:

    Mark> Eric - If you are going to make changes here, would it be
    Mark> possible to pass a sequence of colors, one for each line
    Mark> segment in the collection.  You can check, for example,
    Mark> whether the length of the sequence is equal to the number of
    Mark> segments.  Would be very helpful for some people, as I have
    Mark> seen requests for this possibility several times on the
    Mark> list.

Unless, I am misunderstanding you, you can already do that.  For
example, this is what scatter and polor do to make each element of the
collection a different color.

Eric is talking about a convenience function so that you can pass
arbitrary colors arguments rather than rgba, ie the equivalent of

  from matplotlib.colors import colorConverter
  colors = [colorConverter.to_rgba(x) for x in 'yellow', 0.5, (1,0,0,0.5)]

you can then pass colors to a collection with three elements and get
the three colors yellow, gray and transparent red

JDH

Eric -

If you are going to make changes here, would it be possible to pass a
sequence of colors, one for each line segment in the collection.
You can check, for example, whether the length of the sequence is equal to
the number of segments.
Would be very helpful for some people, as I have seen requests for this
possibility several times on the list.

Thanks, Mark



> --__--__--
>
> Message: 3
> Date: Tue, 09 May 2006 14:44:07 -1000
> From: Eric Firing <ef...@ha...>
> Organization: University of Hawaii
> To: John Hunter <jdh...@ni...>
> CC: matplotlib development list <mat...@li...>
> Subject: [matplotlib-devel] color argument to collections
>
> John,
>
> Collections would be easier to use if they did not have the restriction
> (from the docstring):
>
>      All color args to a collection are sequences of rgba tuples
>
> It would be easy to remove this restriction; shall I do it, or is there
> a reason to leave the restriction in place?  (The error message that
> results from violating the restriction is not helpful, and it would be
> as easy to remove the restriction as to improve the error handling.)
>
> Eric
>
>
>
>

Hi. A long while ago I had sent out an email asking if anyone was 
interested in an XML library for plotting with matplotlib. It seemed the 
general consensus was no, though it might be nice as a backend for 
saving files. So I developed the XML library for my own purposes, and 
have been using it for some time.

I thought I might as well clean it up, package it, and release it in the 
wild. I'm not sure if this would even qualify as an alpha release, 
perhaps more of a RFC, but if anyone is interested, and wants to give 
some comments, let me know. While it has gotten a good amount of use 
(including a soon to be published paper), it has evolved to fit my needs 
more than anything else. So in the clean up, I tried to refractor some 
saneness into it, and had to fix some things in the process. I tried to 
test as much of it as possible, but I'm sure I forgot some obvious 
things as well.

It is trying to serve 3 purposes:
(1) Framework for making publishable figures easy
(2) Provide an easy way to allow pylab figures to be saveable/loadable 
and editable by human
(3) Provide a general framework for a higher level plotting library

I'm hoping to in the near future write the backend to pylab to save in 
the XML format. It should (hopefully) be fairly trivial..

It can be found (this includes some documentation and examples):
www.cns.nyu.edu/~abes/xmlplot.tar.gz

Thanks,

Abe

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> John, Collections would be easier to use if they did not
    Eric> have the restriction (from the docstring):

    Eric>      All color args to a collection are sequences of rgba
    Eric> tuples

    Eric> It would be easy to remove this restriction; shall I do it,
    Eric> or is there a reason to leave the restriction in place?
    Eric> (The error message that results from violating the
    Eric> restriction is not helpful, and it would be as easy to
    Eric> remove the restriction as to improve the error handling.)

I think it's fine to remove it, but note that you have to be careful
to avoid ambiguity.  How would you interpret

  color = (0.25, 0.5, 0.75, 1.0)

Is this one rgba color or 4 grayscales?  

Because mpl accepts lots of different types of args for colors, there
will probably be some ambiguous cases, thought these will be very rare
corner cases.  Just document what the behavior is, and everyone should
be happy.  I think you could do the same for the linewidths, etc.  Eg
if scalar, interpret as a single linewidth for all elements of the
collection?

Or were you intending to preserve the requirement that one pass
sequences, but allow versatile color args in the sequence?

JDH

John,

Collections would be easier to use if they did not have the restriction 
(from the docstring):

     All color args to a collection are sequences of rgba tuples

It would be easy to remove this restriction; shall I do it, or is there 
a reason to leave the restriction in place?  (The error message that 
results from violating the restriction is not helpful, and it would be 
as easy to remove the restriction as to improve the error handling.)

Eric

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
>     Eric> John (Hunter), Paul (Kienzle), Alex (Mont), I have fixed
>     Eric> some of the problems with pcolormesh reported by George
> 
> I think some of these changes are not playing well with numarray

Or with Numeric.

It is fixed in svn now.  I needed to use Travis's ma.getmaskorNone() trick.

I will breathe a sigh of relief on that happy day when we can drop 
support for Numeric and numarray...

Eric