matplotlib-devel Mailing List for matplotlib

On Wed, Mar 27, 2013 at 2:10 PM, Michael Droettboom <md...@st...> wrote:
> On 03/27/2013 02:09 PM, Damon McDougall wrote:
>>
>> On Wed, Mar 27, 2013 at 8:03 AM, Michael Droettboom <md...@st...>
>> wrote:
>>>
>>> Thanks again to the packagers for their quick work (as usual). I've gone
>>> ahead and made the official announcement.
>>
>> On matplotlib-users? I don't see it there...
>
>
> Thanks for pointing that out -- it seems to have been rejected the first
> time around...
Think we're good now. Thanks!
>
> Mike
>
>
>>
>>> Let's continue to put simple bugfixes on the 1.2.x branch -- it's not
>>> clear
>>> there will be a 1.2.2, but it's much easier to make a bugfix release from
>>> a
>>> branch that has been maintained as such than to try to cherry-pick
>>> critical
>>> bugfixes later.
>>>
>>> Cheers,
>>> Mike
>>>
>>>
>>> On 03/26/2013 12:53 PM, Damon McDougall wrote:
>>>>
>>>> On Tue, Mar 26, 2013 at 9:50 AM, Michael Droettboom <md...@st...>
>>>> wrote:
>>>>>
>>>>> I have tagged and uploaded the tarball for the 1.2.1 final release.
>>>>> Thanks to all for their hard work on this! I think the quality of this
>>>>> release is very high.
>>>>>
>>>>>
>>>>>
>>>>> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.2.1/matplotlib-1.2.1.tar.gz/download
>>>>>
>>>>> Once the binaries have been posted and the website download links have
>>>>> been updated, I'll make a formal announcement in the usual channels.
>>>>>
>>>>> Mike
>>>>
>>>> Thanks, Mike, for your hard work and perseverance.
>>>>
>>>> As usual Russell, let me know if you have build issues on the Mac.
>>>>
>>>> Happy Tuesday everybody.
>>>> 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

On 03/27/2013 02:09 PM, Damon McDougall wrote:
> On Wed, Mar 27, 2013 at 8:03 AM, Michael Droettboom <md...@st...> wrote:
>> Thanks again to the packagers for their quick work (as usual). I've gone
>> ahead and made the official announcement.
> On matplotlib-users? I don't see it there...
Thanks for pointing that out -- it seems to have been rejected the first 
time around...
Mike
>
>> Let's continue to put simple bugfixes on the 1.2.x branch -- it's not clear
>> there will be a 1.2.2, but it's much easier to make a bugfix release from a
>> branch that has been maintained as such than to try to cherry-pick critical
>> bugfixes later.
>>
>> Cheers,
>> Mike
>>
>>
>> On 03/26/2013 12:53 PM, Damon McDougall wrote:
>>> On Tue, Mar 26, 2013 at 9:50 AM, Michael Droettboom <md...@st...>
>>> wrote:
>>>> I have tagged and uploaded the tarball for the 1.2.1 final release.
>>>> Thanks to all for their hard work on this! I think the quality of this
>>>> release is very high.
>>>>
>>>>
>>>> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.2.1/matplotlib-1.2.1.tar.gz/download
>>>>
>>>> Once the binaries have been posted and the website download links have
>>>> been updated, I'll make a formal announcement in the usual channels.
>>>>
>>>> Mike
>>> Thanks, Mike, for your hard work and perseverance.
>>>
>>> As usual Russell, let me know if you have build issues on the Mac.
>>>
>>> Happy Tuesday everybody.
>>> Best wishes,
>>> Damon
>>>
>
>

On Wed, Mar 27, 2013 at 8:03 AM, Michael Droettboom <md...@st...> wrote:
> Thanks again to the packagers for their quick work (as usual). I've gone
> ahead and made the official announcement.
On matplotlib-users? I don't see it there...
>
> Let's continue to put simple bugfixes on the 1.2.x branch -- it's not clear
> there will be a 1.2.2, but it's much easier to make a bugfix release from a
> branch that has been maintained as such than to try to cherry-pick critical
> bugfixes later.
>
> Cheers,
> Mike
>
>
> On 03/26/2013 12:53 PM, Damon McDougall wrote:
>>
>> On Tue, Mar 26, 2013 at 9:50 AM, Michael Droettboom <md...@st...>
>> wrote:
>>>
>>> I have tagged and uploaded the tarball for the 1.2.1 final release.
>>> Thanks to all for their hard work on this! I think the quality of this
>>> release is very high.
>>>
>>>
>>> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.2.1/matplotlib-1.2.1.tar.gz/download
>>>
>>> Once the binaries have been posted and the website download links have
>>> been updated, I'll make a formal announcement in the usual channels.
>>>
>>> Mike
>>
>> Thanks, Mike, for your hard work and perseverance.
>>
>> As usual Russell, let me know if you have build issues on the Mac.
>>
>> Happy Tuesday everybody.
>> 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

Thanks again to the packagers for their quick work (as usual). I've 
gone ahead and made the official announcement.
Let's continue to put simple bugfixes on the 1.2.x branch -- it's not 
clear there will be a 1.2.2, but it's much easier to make a bugfix 
release from a branch that has been maintained as such than to try to 
cherry-pick critical bugfixes later.
Cheers,
Mike
On 03/26/2013 12:53 PM, Damon McDougall wrote:
> On Tue, Mar 26, 2013 at 9:50 AM, Michael Droettboom <md...@st...> wrote:
>> I have tagged and uploaded the tarball for the 1.2.1 final release.
>> Thanks to all for their hard work on this! I think the quality of this
>> release is very high.
>>
>> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.2.1/matplotlib-1.2.1.tar.gz/download
>>
>> Once the binaries have been posted and the website download links have
>> been updated, I'll make a formal announcement in the usual channels.
>>
>> Mike
> Thanks, Mike, for your hard work and perseverance.
>
> As usual Russell, let me know if you have build issues on the Mac.
>
> Happy Tuesday everybody.
> Best wishes,
> Damon
>

On Tue, Mar 26, 2013 at 9:50 AM, Michael Droettboom <md...@st...> wrote:
> I have tagged and uploaded the tarball for the 1.2.1 final release.
> Thanks to all for their hard work on this! I think the quality of this
> release is very high.
>
> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.2.1/matplotlib-1.2.1.tar.gz/download
>
> Once the binaries have been posted and the website download links have
> been updated, I'll make a formal announcement in the usual channels.
>
> Mike
Thanks, Mike, for your hard work and perseverance.
As usual Russell, let me know if you have build issues on the Mac.
Happy Tuesday everybody.
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

On 03/26/2013 11:18 AM, Michael Droettboom wrote:
> On 03/26/2013 10:57 AM, Damon McDougall wrote:
>> On Tue, Mar 26, 2013 at 8:25 AM, Benjamin Root <ben...@ou...> wrote:
>>> On Fri, Mar 22, 2013 at 12:35 PM, Michael Droettboom <md...@st...>
>>> 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.
>>>>
>>>> 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.
>>>>
>>>> I've set up a wiki page here:
>>>>
>>>> https://github.com/matplotlib/matplotlib/wiki/Scipy-2013
>>>>
>>> Getting a bit back on the original topic of the SciPy sprints, there 
>>> are
>>> some things I have learned from last year's sprints. First off, 
>>> there are
>>> going to be a lot of newbies there who do not even have a developer 
>>> setup,
>>> let alone a source install of matplotlib. Myself and a few other 
>>> people
>>> spent several hours fumbling around with getting the Mac users set up
>>> properly. With me not being a Mac user, I felt very helpless. We 
>>> need to
>>> be better prepared for these users (as well as the Windows users).
>>>
>>> Second, working on matplotlib isn't very "sexy" (at least, insofar as
>>> working on ipython, or one of the scikits). Most of the attendees are
>>> specialized scientists who only cares enough about matplotlib to 
>>> produce
>>> "the plot" for their work. Getting attendees to join your sprint is 
>>> a hard
>>> sell. This is not meant to discourage you, but rather to help 
>>> better frame
>>> what the tasks and goals should be for matplotlib at the sprints.
>>>
>>> I wish I was this prepared last year. You are off to a much better 
>>> start
>>> than I was.
>>>
>>> Cheers!
>>> Ben Root
>> Ben,
>>
>> This is incredibly useful information. I have never been to a sprint
>> before so this valuable knowledge to have. Since I'm a mac user,
>> perhaps I could put together a 'source install walkthrough' or
>> something? That might help us save some time fumbling at the
>> beginning of the sprint.
>>
> Damon -- I think that would be very helpful. I can do the same for 
> major Linux distros. Sadly,Windows is much more complex and I'm not 
> even terribly up on current best practices there. Any volunteers?
Also -- should we set up a shared place (either a git repo or just a 
wiki page) to collaborate on any of these materials?
Mike

On 03/26/2013 10:57 AM, Damon McDougall wrote:
> On Tue, Mar 26, 2013 at 8:25 AM, Benjamin Root <ben...@ou...> wrote:
>> On Fri, Mar 22, 2013 at 12:35 PM, Michael Droettboom <md...@st...>
>> 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.
>>>
>>> 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.
>>>
>>> I've set up a wiki page here:
>>>
>>> https://github.com/matplotlib/matplotlib/wiki/Scipy-2013
>>>
>> Getting a bit back on the original topic of the SciPy sprints, there are
>> some things I have learned from last year's sprints. First off, there are
>> going to be a lot of newbies there who do not even have a developer setup,
>> let alone a source install of matplotlib. Myself and a few other people
>> spent several hours fumbling around with getting the Mac users set up
>> properly. With me not being a Mac user, I felt very helpless. We need to
>> be better prepared for these users (as well as the Windows users).
>>
>> Second, working on matplotlib isn't very "sexy" (at least, insofar as
>> working on ipython, or one of the scikits). Most of the attendees are
>> specialized scientists who only cares enough about matplotlib to produce
>> "the plot" for their work. Getting attendees to join your sprint is a hard
>> sell. This is not meant to discourage you, but rather to help better frame
>> what the tasks and goals should be for matplotlib at the sprints.
>>
>> I wish I was this prepared last year. You are off to a much better start
>> than I was.
>>
>> Cheers!
>> Ben Root
> Ben,
>
> This is incredibly useful information. I have never been to a sprint
> before so this valuable knowledge to have. Since I'm a mac user,
> perhaps I could put together a 'source install walkthrough' or
> something? That might help us save some time fumbling at the
> beginning of the sprint.
>
Damon -- I think that would be very helpful. I can do the same for 
major Linux distros. Sadly,Windows is much more complex and I'm not 
even terribly up on current best practices there. Any volunteers?
Mike

I have tagged and uploaded the tarball for the 1.2.1 final release. 
Thanks to all for their hard work on this! I think the quality of this 
release is very high.
http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.2.1/matplotlib-1.2.1.tar.gz/download
Once the binaries have been posted and the website download links have 
been updated, I'll make a formal announcement in the usual channels.
Mike

On Tue, Mar 26, 2013 at 8:25 AM, Benjamin Root <ben...@ou...> wrote:
>
> On Fri, Mar 22, 2013 at 12:35 PM, Michael Droettboom <md...@st...>
> 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.
>>
>> 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.
>>
>> I've set up a wiki page here:
>>
>> https://github.com/matplotlib/matplotlib/wiki/Scipy-2013
>>
>
> Getting a bit back on the original topic of the SciPy sprints, there are
> some things I have learned from last year's sprints. First off, there are
> going to be a lot of newbies there who do not even have a developer setup,
> let alone a source install of matplotlib. Myself and a few other people
> spent several hours fumbling around with getting the Mac users set up
> properly. With me not being a Mac user, I felt very helpless. We need to
> be better prepared for these users (as well as the Windows users).
>
> Second, working on matplotlib isn't very "sexy" (at least, insofar as
> working on ipython, or one of the scikits). Most of the attendees are
> specialized scientists who only cares enough about matplotlib to produce
> "the plot" for their work. Getting attendees to join your sprint is a hard
> sell. This is not meant to discourage you, but rather to help better frame
> what the tasks and goals should be for matplotlib at the sprints.
>
> I wish I was this prepared last year. You are off to a much better start
> than I was.
>
> Cheers!
> Ben Root
Ben,
This is incredibly useful information. I have never been to a sprint
before so this valuable knowledge to have. Since I'm a mac user,
perhaps I could put together a 'source install walkthrough' or
something? That might help us save some time fumbling at the
beginning of the sprint.
-- 
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

On Fri, Mar 22, 2013 at 12:35 PM, Michael Droettboom <md...@st...>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.
>
> 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.
>
> I've set up a wiki page here:
>
> https://github.com/matplotlib/matplotlib/wiki/Scipy-2013
>
>
Getting a bit back on the original topic of the SciPy sprints, there are
some things I have learned from last year's sprints. First off, there are
going to be a lot of newbies there who do not even have a developer setup,
let alone a source install of matplotlib. Myself and a few other people
spent several hours fumbling around with getting the Mac users set up
properly. With me not being a Mac user, I felt very helpless. We need to
be better prepared for these users (as well as the Windows users).
Second, working on matplotlib isn't very "sexy" (at least, insofar as
working on ipython, or one of the scikits). Most of the attendees are
specialized scientists who only cares enough about matplotlib to produce
"the plot" for their work. Getting attendees to join your sprint is a hard
sell. This is not meant to discourage you, but rather to help better frame
what the tasks and goals should be for matplotlib at the sprints.
I wish I was this prepared last year. You are off to a much better start
than I was.
Cheers!
Ben Root

Benjamin Root writes:
 > 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.
Just for the record: over the last few years I have assembled a
document which is more a collection of facts and tricks on
Numpy/Scipy/Matplotlib which seems orthogonal to your goals. I am
trying to get students in numerical analysis or similar courses
operational as quickly as possible. So I am taking pylab as a
baseline. (So really a Matlab replacement, although most students
will not have had any close contact with Matlab...)
Any comments are welcome. Some more nice matplotlib examples are on
my wish list, but I have not found time yet...
PDF: http://math.jacobs-university.de/oliver/teaching/numpy-intro/numpy-intro.pdf
HTML: http://math.jacobs-university.de/oliver/teaching/numpy-intro/numpy-intro/index.html
Sources: http://math.jacobs-university.de/oliver/teaching/numpy-intro/
I have been argued back and forth with myself whether I should make it
more pythonic (as most of the "official" matplotlib examples are), but
then on the ground where class time is precious, I came to appreciate
the simplicity of pylab-style code.
Regards,
Marcel
---------------------------------------------------------------------
Marcel Oliver Phone: +49-421-200-3212 
School of Engineering and Science Fax: +49-421-200-3103
Jacobs University m.o...@ja...
Campus Ring 1 ol...@me... 
28759 Bremen, Germany http://math.jacobs-university.de/oliver
---------------------------------------------------------------------

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
>

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 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

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