matplotlib-devel Mailing List for matplotlib

These are fantastic slides.  It would be great to include them in some 
form for a replacement for some parts of the docs that are getting a 
little long in the tooth.

I particularly like the reference section -- we have some of that in the 
main docs, but not enough.  I think as Nelle Varaquoax and others are 
moving forward on the documentation reorganization, some of those 
figures, such as the marker style reference, would make fantastic additions.

Mike

On 03/25/2013 02:21 PM, Nicolas Rougier wrote:
>
> One idea I've been using is to show explicitly what's going on in the background when you're using defaults by instantiating all the default settings:
>
> http://www.loria.fr/~rougier/teaching/matplotlib/#using-defaults
>
> versus
>
> http://www.loria.fr/~rougier/teaching/matplotlib/#instantiating-defaults
>
>
> Nicolas
>
>
> On Mar 25, 2013, at 18:43 , Damon McDougall wrote:
>
>> On Mon, Mar 25, 2013 at 12:17 PM, Thomas A Caswell
>> <tca...@uc...> wrote:
>>> I think there is something to be said for not starting from pylab.
>>> Answering questions on SO, a good chunk of them (by volume) can be
>>> traced back to not understanding the magic that pylab is doing for you
>>> in the background or not even knowing magic is being done for you.
>>> Starting from pylab makes easy stuff trivial, but slightly more
>>> complicated things a much bigger lift to figure out how to do (as
>>> compared to the conceptual difference in how hard they are).
>>>
>>> A tutorial that starts from the POV of building the figure out of
>>> parts sounds like a good idea to me.   At a minimum, a key with the
>>> different parts of the figure labeled with what family of classes
>>> control them would be great (or if something like that already exists
>>> make it easier to find;))
>>>
>>> Tom
>>>
>>> On Mon, Mar 25, 2013 at 12:03 PM, Benjamin Root <ben...@ou...> wrote:
>>>> On Mon, Mar 25, 2013 at 12:46 PM, Phil Elson <pel...@gm...> wrote:
>>>>>> I am putting together a beginners tutorial proposal that I will submit
>>>>>> soon
>>>>> That's great to hear! Are you planning on making the tutorial material
>>>>> part of mpl's docs or using the content that is already out there?
>>>>>
>>>>>
>>>> It is all new stuff, but I have been taking inspirations from other
>>>> tutorials I have seen and said to myself "You are all teaching it wrong!"
>>>> :-P
>>>>
>>>> I am ignoring pylab (risky, I know), starting with a *very* basic NumPy
>>>> primer, and then moving on to teach matplotlib from the perspective of "here
>>>> are what the parts of a plot are called and what they are for, and see what
>>>> happens when we put those parts together".  It is an ingredients approach,
>>>> essentially.
>>>>
>>>> Hopefully, aspects of it will be useful for the docs when it is finished.  I
>>>> am also hoping that having a ipython notebook version of it will help others
>>>> to improve it for future conferences (there should always be an intro to
>>>> matplotlib tutorial at SciPy).
>>>>
>>>> Ben Root
>> That seems like a good approach to me.  Thanks for doing this.  I just
>> submitted a tutorial, but it assumes people know how to make a line
>> plot already.  Perhaps I should learn from this assumption and
>> communicate better on this list and garner interest about what people
>> would like to see a priori.
>>
>> Thanks for putting this together, Ben.  Out of interest, are you
>> diving straight into the pyplot state machine, or are you taking the
>> more object oriented approach of setting up the canvas and figure
>> object explicitly?  I use the OO approach all the time, but I only use
>> the non-interactive backends like Agg and PDF.
>>
>> On a not-too-orthogonal note, I'd personally like to see a tutorial on
>> hooking in mpl into other GUI-like applications.  Paraview seems to do
>> this a little, but I'd like to see someone do a soup-to-nuts
>> walkthrough for it, just because I have no experience doing this;  I'm
>> a terminal hermit.
>>
>> Best wishes,
>> Damon
>>
>> -- 
>> Damon McDougall
>> http://www.damon-is-a-geek.com
>> Institute for Computational Engineering Sciences
>> 201 E. 24th St.
>> Stop C0200
>> The University of Texas at Austin
>> Austin, TX 78712-1229
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

One idea I've been using is to show explicitly what's going on in the background when you're using defaults by instantiating all the default settings:

http://www.loria.fr/~rougier/teaching/matplotlib/#using-defaults

versus

http://www.loria.fr/~rougier/teaching/matplotlib/#instantiating-defaults


Nicolas


On Mar 25, 2013, at 18:43 , Damon McDougall wrote:

> On Mon, Mar 25, 2013 at 12:17 PM, Thomas A Caswell
> <tca...@uc...> wrote:
>> I think there is something to be said for not starting from pylab.
>> Answering questions on SO, a good chunk of them (by volume) can be
>> traced back to not understanding the magic that pylab is doing for you
>> in the background or not even knowing magic is being done for you.
>> Starting from pylab makes easy stuff trivial, but slightly more
>> complicated things a much bigger lift to figure out how to do (as
>> compared to the conceptual difference in how hard they are).
>> 
>> A tutorial that starts from the POV of building the figure out of
>> parts sounds like a good idea to me.   At a minimum, a key with the
>> different parts of the figure labeled with what family of classes
>> control them would be great (or if something like that already exists
>> make it easier to find;))
>> 
>> Tom
>> 
>> On Mon, Mar 25, 2013 at 12:03 PM, Benjamin Root <ben...@ou...> wrote:
>>> 
>>> On Mon, Mar 25, 2013 at 12:46 PM, Phil Elson <pel...@gm...> wrote:
>>>> 
>>>>> I am putting together a beginners tutorial proposal that I will submit
>>>>> soon
>>>> 
>>>> That's great to hear! Are you planning on making the tutorial material
>>>> part of mpl's docs or using the content that is already out there?
>>>> 
>>>> 
>>> 
>>> It is all new stuff, but I have been taking inspirations from other
>>> tutorials I have seen and said to myself "You are all teaching it wrong!"
>>> :-P
>>> 
>>> I am ignoring pylab (risky, I know), starting with a *very* basic NumPy
>>> primer, and then moving on to teach matplotlib from the perspective of "here
>>> are what the parts of a plot are called and what they are for, and see what
>>> happens when we put those parts together".  It is an ingredients approach,
>>> essentially.
>>> 
>>> Hopefully, aspects of it will be useful for the docs when it is finished.  I
>>> am also hoping that having a ipython notebook version of it will help others
>>> to improve it for future conferences (there should always be an intro to
>>> matplotlib tutorial at SciPy).
>>> 
>>> Ben Root
> 
> That seems like a good approach to me.  Thanks for doing this.  I just
> submitted a tutorial, but it assumes people know how to make a line
> plot already.  Perhaps I should learn from this assumption and
> communicate better on this list and garner interest about what people
> would like to see a priori.
> 
> Thanks for putting this together, Ben.  Out of interest, are you
> diving straight into the pyplot state machine, or are you taking the
> more object oriented approach of setting up the canvas and figure
> object explicitly?  I use the OO approach all the time, but I only use
> the non-interactive backends like Agg and PDF.
> 
> On a not-too-orthogonal note, I'd personally like to see a tutorial on
> hooking in mpl into other GUI-like applications.  Paraview seems to do
> this a little, but I'd like to see someone do a soup-to-nuts
> walkthrough for it, just because I have no experience doing this;  I'm
> a terminal hermit.
> 
> Best wishes,
> Damon
> 
> -- 
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Mon, Mar 25, 2013 at 12:17 PM, Thomas A Caswell
<tca...@uc...> wrote:
> I think there is something to be said for not starting from pylab.
> Answering questions on SO, a good chunk of them (by volume) can be
> traced back to not understanding the magic that pylab is doing for you
> in the background or not even knowing magic is being done for you.
> Starting from pylab makes easy stuff trivial, but slightly more
> complicated things a much bigger lift to figure out how to do (as
> compared to the conceptual difference in how hard they are).
>
> A tutorial that starts from the POV of building the figure out of
> parts sounds like a good idea to me.   At a minimum, a key with the
> different parts of the figure labeled with what family of classes
> control them would be great (or if something like that already exists
> make it easier to find;))
>
> Tom
>
> On Mon, Mar 25, 2013 at 12:03 PM, Benjamin Root <ben...@ou...> wrote:
>>
>> On Mon, Mar 25, 2013 at 12:46 PM, Phil Elson <pel...@gm...> wrote:
>>>
>>> >I am putting together a beginners tutorial proposal that I will submit
>>> > soon
>>>
>>> That's great to hear! Are you planning on making the tutorial material
>>> part of mpl's docs or using the content that is already out there?
>>>
>>>
>>
>> It is all new stuff, but I have been taking inspirations from other
>> tutorials I have seen and said to myself "You are all teaching it wrong!"
>> :-P
>>
>> I am ignoring pylab (risky, I know), starting with a *very* basic NumPy
>> primer, and then moving on to teach matplotlib from the perspective of "here
>> are what the parts of a plot are called and what they are for, and see what
>> happens when we put those parts together".  It is an ingredients approach,
>> essentially.
>>
>> Hopefully, aspects of it will be useful for the docs when it is finished.  I
>> am also hoping that having a ipython notebook version of it will help others
>> to improve it for future conferences (there should always be an intro to
>> matplotlib tutorial at SciPy).
>>
>> Ben Root

That seems like a good approach to me.  Thanks for doing this.  I just
submitted a tutorial, but it assumes people know how to make a line
plot already.  Perhaps I should learn from this assumption and
communicate better on this list and garner interest about what people
would like to see a priori.

Thanks for putting this together, Ben.  Out of interest, are you
diving straight into the pyplot state machine, or are you taking the
more object oriented approach of setting up the canvas and figure
object explicitly?  I use the OO approach all the time, but I only use
the non-interactive backends like Agg and PDF.

On a not-too-orthogonal note, I'd personally like to see a tutorial on
hooking in mpl into other GUI-like applications.  Paraview seems to do
this a little, but I'd like to see someone do a soup-to-nuts
walkthrough for it, just because I have no experience doing this;  I'm
a terminal hermit.

Best wishes,
Damon

-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

I think there is something to be said for not starting from pylab.
Answering questions on SO, a good chunk of them (by volume) can be
traced back to not understanding the magic that pylab is doing for you
in the background or not even knowing magic is being done for you.
Starting from pylab makes easy stuff trivial, but slightly more
complicated things a much bigger lift to figure out how to do (as
compared to the conceptual difference in how hard they are).

A tutorial that starts from the POV of building the figure out of
parts sounds like a good idea to me.   At a minimum, a key with the
different parts of the figure labeled with what family of classes
control them would be great (or if something like that already exists
make it easier to find;))

Tom

On Mon, Mar 25, 2013 at 12:03 PM, Benjamin Root <ben...@ou...> wrote:
>
> On Mon, Mar 25, 2013 at 12:46 PM, Phil Elson <pel...@gm...> wrote:
>>
>> >I am putting together a beginners tutorial proposal that I will submit
>> > soon
>>
>> That's great to hear! Are you planning on making the tutorial material
>> part of mpl's docs or using the content that is already out there?
>>
>>
>
> It is all new stuff, but I have been taking inspirations from other
> tutorials I have seen and said to myself "You are all teaching it wrong!"
> :-P
>
> I am ignoring pylab (risky, I know), starting with a *very* basic NumPy
> primer, and then moving on to teach matplotlib from the perspective of "here
> are what the parts of a plot are called and what they are for, and see what
> happens when we put those parts together".  It is an ingredients approach,
> essentially.
>
> Hopefully, aspects of it will be useful for the docs when it is finished.  I
> am also hoping that having a ipython notebook version of it will help others
> to improve it for future conferences (there should always be an intro to
> matplotlib tutorial at SciPy).
>
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>



-- 
Thomas A Caswell
PhD Candidate University of Chicago
Nagel and Gardel labs
tca...@uc...
jfi.uchicago.edu/~tcaswell
o: 773.702.7204

On Mon, Mar 25, 2013 at 12:46 PM, Phil Elson <pel...@gm...> wrote:

> >I am putting together a beginners tutorial proposal that I will submit
> soon
>
> That's great to hear! Are you planning on making the tutorial material
> part of mpl's docs or using the content that is already out there?
>
>
>
It is all new stuff, but I have been taking inspirations from other
tutorials I have seen and said to myself "You are all teaching it wrong!"
:-P

I am ignoring pylab (risky, I know), starting with a *very* basic NumPy
primer, and then moving on to teach matplotlib from the perspective of
"here are what the parts of a plot are called and what they are for, and
see what happens when we put those parts together".  It is an ingredients
approach, essentially.

Hopefully, aspects of it will be useful for the docs when it is finished.
I am also hoping that having a ipython notebook version of it will help
others to improve it for future conferences (there should always be an
intro to matplotlib tutorial at SciPy).

Ben Root

>I am putting together a beginners tutorial proposal that I will submit soon

That's great to hear! Are you planning on making the tutorial material part
of mpl's docs or using the content that is already out there?



On 25 March 2013 16:16, Benjamin Root <ben...@ou...> wrote:

> I am putting together a beginners tutorial proposal that I will submit
> soon, depending on the feedback from the Guinea Pigs--- uhm, I mean,
> coworkers tomorrow.
>
> Ben Root
>
>

I am putting together a beginners tutorial proposal that I will submit
soon, depending on the feedback from the Guinea Pigs--- uhm, I mean,
coworkers tomorrow.

Ben Root

On Mon, Mar 25, 2013 at 2:03 AM, Eric Firing <ef...@ha...> wrote:
> On 2013/03/24 12:14 PM, Benjamin Root wrote:
>> So, for plot(), scatter() and other plotting functions, we can provide a
>> label= kwarg so that a legend() can automatically populate the legend,
>> making it extremely easy and convenient for making legends.  But for
>> image-based (scalar mappable) type plotting functions like imshow() and
>> contourf(), the label kwarg doesn't do anything useful, but the
>> colorbar() is sort of analogous to a legend(), but for scalar mappables.
>>
>> Does it make sense to others for the following to be equivalent:
>>
>>  > plt.imshow(z)
>>  > cbar = plt.colorbar()
>>  > cbar.set_label('foobar')
>>
>>  > plt.imshow(z, label='foobar')
>>  > plt.colorbar()
>>
>
> I understand your argument, but it feels a bit odd.  To me it would be
> more natural for colorbar() itself to accept a label kwarg.  I have no
> idea why I didn't do that long ago.
>
> The two ideas are not mutually exclusive.

Yeah, I agree with Eric here; plt.colorbar(label='foo') feels more
intuitive to me.

>
> Eric
>
>>
>> I found that it is a small change to make this work, I just wanted to
>> know if others think this makes sense before putting in the time to add
>> documentation, modify examples and such.
>>
>> Cheers!
>> Ben Root
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>>
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

OOI Is anyone planning to run an advanced matplotlib tutorial this year?

I've added a few ideas to
https://github.com/matplotlib/matplotlib/wiki/Scipy-2013 - some are more
advanced than others and would need a bit of planning should we decide to
run with them.



On 23 March 2013 17:06, Damon McDougall <dam...@gm...> wrote:

> On Fri, Mar 22, 2013 at 12:11 PM, Nelle Varoquaux
> <nel...@gm...> wrote:
> >
> >
> >
> > On 22 March 2013 18:06, Michael Droettboom <md...@st...> wrote:
> >>
> >> On 03/22/2013 12:45 PM, Nelle Varoquaux wrote:
> >>
> >>
> >>> I'm hoping to host a matplotlib sprint during the final two days of
> Scipy
> >>> 2013 this year, and I hope to see as many as possible of you there.  I
> think
> >>> it's also really important to bring new developers into sprints,
> because
> >>> it's such an efficient way to get people familiar with the code base.
>
> Awesome idea.  I am for sure in.  In fact, I work in Austin now; it'd
> be great to actually meet some of you in person.  We should share some
> breakfast tacos or interior Mexican food!
>
> >> Being in Europe, it is very unlikely I'll come to Scipy this year, but I
> >> think it is a great idea to organize a sprint during this period.
> >>
> >>
> >> I'll also try to set up some sort of remote communication tool (such as
> >> Google Hangouts, or even just IRC) so that people can "participate" in
> the
> >> sprint remotely.
> >
> >
> > There's a #matplotlib chanel on irc, where a dozen people hang out. That
> > could be a nice place to gather people during the sprint.
>
> Is this on freenode?  I joined it yesterday to scope it out but it was
> pretty quiet.
>
> >
> >>
> >>
> >>
> >>
> >>>
> >>> It might be helpful to start brainstorming now about which projects we
> >>> may want to tackle so that we can have as much in place as possible by
> then
> >>> and hit the ground running.
> >>
> >>
> >> One of the things I think would be great to tackle is the replacement of
> >> the Travis bot. Ideally, I'd like to see a pep8 check of each patch and
> a
> >> daily build of the documentation on master in addition of the tests.
> >>
> >>
> >> Agreed.  That's definitely on my todo list.  We've got some funding
> >> through my employer to pay for continuous integration hosting -- it's
> just
> >> taking a while to work its way through the system.  Once we have some
> sort
> >> of paid hosting system, we should be able to do a lot more than Travis
> >> currently can.
> >>
> >> Mike
> >>
> >>
> >>
> >>>
> >>>
> >>> I've set up a wiki page here:
> >>>
> >>> https://github.com/matplotlib/matplotlib/wiki/Scipy-2013
>
> I have edited the Wiki to confirm my attendance.
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Mon, Mar 25, 2013 at 3:03 AM, Eric Firing <ef...@ha...> wrote:

> On 2013/03/24 12:14 PM, Benjamin Root wrote:
> > So, for plot(), scatter() and other plotting functions, we can provide a
> > label= kwarg so that a legend() can automatically populate the legend,
> > making it extremely easy and convenient for making legends.  But for
> > image-based (scalar mappable) type plotting functions like imshow() and
> > contourf(), the label kwarg doesn't do anything useful, but the
> > colorbar() is sort of analogous to a legend(), but for scalar mappables.
> >
> > Does it make sense to others for the following to be equivalent:
> >
> >  > plt.imshow(z)
> >  > cbar = plt.colorbar()
> >  > cbar.set_label('foobar')
> >
> >  > plt.imshow(z, label='foobar')
> >  > plt.colorbar()
> >
>
> I understand your argument, but it feels a bit odd.  To me it would be
> more natural for colorbar() itself to accept a label kwarg.  I have no
> idea why I didn't do that long ago.
>
> The two ideas are not mutually exclusive.
>
> Eric
>
>
Indeed, it isn't.  The way to make this work is to allow ColorbarBase to
accept a label kwarg.  That's basically all that is needed.  Most of the
work would go into documentation and updating examples.

Ben

In general I like the idea, but I'm not sure what behaviour I would expect
in this case:

plt.imshow(z, label='foobar')
plt.imshow(z, label='wibble')
plt.colorbar()

I suppose it is an analogous problem to:

plt.imshow(z, cmap='hot')
plt.imshow(z, cmap='jet')
plt.colorbar()

Which produces a colorbar for the [current scalar mappable]/gci.

On that basis, I've just convinced myself that your proposal is a good
idea, so +1 from me.





On 25 March 2013 07:03, Eric Firing <ef...@ha...> wrote:

> On 2013/03/24 12:14 PM, Benjamin Root wrote:
> > So, for plot(), scatter() and other plotting functions, we can provide a
> > label= kwarg so that a legend() can automatically populate the legend,
> > making it extremely easy and convenient for making legends.  But for
> > image-based (scalar mappable) type plotting functions like imshow() and
> > contourf(), the label kwarg doesn't do anything useful, but the
> > colorbar() is sort of analogous to a legend(), but for scalar mappables.
> >
> > Does it make sense to others for the following to be equivalent:
> >
> >  > plt.imshow(z)
> >  > cbar = plt.colorbar()
> >  > cbar.set_label('foobar')
> >
> >  > plt.imshow(z, label='foobar')
> >  > plt.colorbar()
> >
>
> I understand your argument, but it feels a bit odd.  To me it would be
> more natural for colorbar() itself to accept a label kwarg.  I have no
> idea why I didn't do that long ago.
>
> The two ideas are not mutually exclusive.
>
> Eric
>
> >
> > I found that it is a small change to make this work, I just wanted to
> > know if others think this makes sense before putting in the time to add
> > documentation, modify examples and such.
> >
> > Cheers!
> > Ben Root
> >
> >
> >
> ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_d2d_mar
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 2013/03/24 12:14 PM, Benjamin Root wrote:
> So, for plot(), scatter() and other plotting functions, we can provide a
> label= kwarg so that a legend() can automatically populate the legend,
> making it extremely easy and convenient for making legends.  But for
> image-based (scalar mappable) type plotting functions like imshow() and
> contourf(), the label kwarg doesn't do anything useful, but the
> colorbar() is sort of analogous to a legend(), but for scalar mappables.
>
> Does it make sense to others for the following to be equivalent:
>
>  > plt.imshow(z)
>  > cbar = plt.colorbar()
>  > cbar.set_label('foobar')
>
>  > plt.imshow(z, label='foobar')
>  > plt.colorbar()
>

I understand your argument, but it feels a bit odd.  To me it would be 
more natural for colorbar() itself to accept a label kwarg.  I have no 
idea why I didn't do that long ago.

The two ideas are not mutually exclusive.

Eric

>
> I found that it is a small change to make this work, I just wanted to
> know if others think this makes sense before putting in the time to add
> documentation, modify examples and such.
>
> Cheers!
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>