matplotlib-devel Mailing List for matplotlib (Page 5)

Eric Firing <efiring@...> writes:
> 
> Anton,
> 
> Yes, I have done things like that in my own code, and basemap has a 
> similar ability to call gca() when an Axes is not supplied. One can 
> even perform the pyplot import on an as-needed basis instead of raising 
> an error. Nevetheless, it still represents what I view as a big change 
> in mpl design, scrambling the state machine pyplot layer into the OO 
> layer. Sometimes this sort of thing is good, sometimes it isn't. In 
> the present case, I am far from convinced that it would be good. I 
> don't see any real benefit at all over the present design. I think that 
> for the sanity of the developers, if nothing else, it is important to 
> maintain some clear layering and hierarchy.
> 
> Eric
>
I completely agree with that, and I just wanted to point out the possibility. 
With the proposed separation of the plots to a separate module, I think, the 
reasonable thing for pyplot would be to wrap the corresponding plot functions 
by feeding gca into the axis argument.
PS for what I think, pyplot right now is way too thick of a layer, 
obstructing an API use of backends.
Anton

On 2013年07月10日 1:11 AM, Anton Akhmerov wrote:
> Eric Firing <efiring@...> writes:
>
>> This would require pyplot to be imported by everything, wouldn't it?
>> That would completely defeat the strategy of having an OO level that
>> doesn't know about pyplot at all, and then having pyplot be the thin top
>> layer.
>
> Requiring pyplot isn't necessary, instead one may merely check if it's
> available. The following is what we do in a similar situation:
>
> try:
> fake_fig = matplotlib.pyplot.figure()
> except AttributeError:
> msg = 'matplotlib.pyplot is unavailable. Execute `import ' \
> 'matplotlib.pyplot` or use a different output mode.'
> raise RuntimeError(msg)
>
> (obviously, one can substitute figure() call to gca())
>
> Anton
Anton,
Yes, I have done things like that in my own code, and basemap has a 
similar ability to call gca() when an Axes is not supplied. One can 
even perform the pyplot import on an as-needed basis instead of raising 
an error. Nevetheless, it still represents what I view as a big change 
in mpl design, scrambling the state machine pyplot layer into the OO 
layer. Sometimes this sort of thing is good, sometimes it isn't. In 
the present case, I am far from convinced that it would be good. I 
don't see any real benefit at all over the present design. I think that 
for the sanity of the developers, if nothing else, it is important to 
maintain some clear layering and hierarchy.
Eric

Eric Firing <efiring@...> writes:
> This would require pyplot to be imported by everything, wouldn't it? 
> That would completely defeat the strategy of having an OO level that 
> doesn't know about pyplot at all, and then having pyplot be the thin top 
> layer.
Requiring pyplot isn't necessary, instead one may merely check if it's 
available. The following is what we do in a similar situation:
 try:
 fake_fig = matplotlib.pyplot.figure()
 except AttributeError:
 msg = 'matplotlib.pyplot is unavailable. Execute `import ' \
 'matplotlib.pyplot` or use a different output mode.'
 raise RuntimeError(msg)
(obviously, one can substitute figure() call to gca())
Anton
> 
> Eric
> 
> > I haven't sat down and thought through all the details of such a change,
> > but I wanted to throw it out there to see if anything sticks.
> >
> > Cheers,
> > -Tony
> >
> >
> > ------------------------------------------------------------------------
------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> > http://pubads.g.doubleclick.net/gampad/clk?
id=48808831&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Matplotlib-devel@...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> 
> --------------------------------------------------------------------------
----
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?
id=48808831&iu=/4140/ostg.clktrk
> 

On Tue, Jul 9, 2013 at 1:43 AM, Nelle Varoquaux
<nel...@gm...>wrote:
> On 9 July 2013 08:24, Eric Firing <ef...@ha...> wrote:
> > On 2013年07月08日 7:19 PM, Tony Yu wrote:
> >> This is an idea that's been kicking around in my head for awhile.
> >> Basically, the Axes class is way too expansive. Nelle made a major step
> >> in the right direction with a PR that split it up into plotting and
> >> non-plotting methods:
> >>
> >> https://github.com/matplotlib/matplotlib/pull/1931/files
> >>
> >> What I'd like to see is something that further separates plotting
> >> methods into many smaller sub-modules/-packages. Organizing the code
> >> this way would make it easier (for me at least) to read, understand, and
> >> make changes to the code.
> >>
> >> I think that this could be done in an API-compatible way. In fact, a few
> >> of the plotting methods are already implemented this way: In other
> >> words, the bulk of the methods are implemented as functions outside of
> >> Axes, and the Axes methods that are just thin wrappers around those
> >> functions (or classes). See, for example, `streamplot`, `barbs`, and
> >> `quiver` methods
> >
> > I agree. I would like to see logical groups of plot types broken out
> > into modules.
>
> That's the second step in the refactoring of the axes module.
> We now have to discuss how to organize plots in subtypes that make
> sense. At Scipy, we discussed a bit about it, and we think it should
> follow the same organization as the gallery, but I don't know whether
> the gallery reorganization is logical enough right now to start the
> refactoring straight away.
>
I knew I should have dropped by the matplotlib sprints :) The gallery
categories really aren't that logical, but as long as the functions aren't
meant to be directly imported from their sub-modules (instead you would use
the Axes method or pyplot function), then nothing needs to be permanent,
right?
>
> Should we discuss about this here, or in a ticket?
>
It's probably easier to discuss on a new ticket.
Cheers,
-Tony

On Tue, Jul 9, 2013 at 1:24 AM, Eric Firing <ef...@ha...> wrote:
<snip>
This would require pyplot to be imported by everything, wouldn't it?
> That would completely defeat the strategy of having an OO level that
> doesn't know about pyplot at all, and then having pyplot be the thin top
> layer.
>
Ahh, you're right! Like I said, I haven't really sat down and thought
through all the details :)
>
> Eric
>
> > I haven't sat down and thought through all the details of such a change,
> > but I wanted to throw it out there to see if anything sticks.
> >
> > Cheers,
> > -Tony
>
>

I second Eric's concern about pyplot being imported into everything. It
will really mess up the people that are embedding matplotlib into guis
because pyplot starts up gui mainloops if you are using an interactive
backend.
There is a genre of question on SO that is 'why isn't pyplot playing nice
with my gui'.
Tom
On Tue, Jul 9, 2013 at 1:43 AM, Nelle Varoquaux
<nel...@gm...>wrote:
> On 9 July 2013 08:24, Eric Firing <ef...@ha...> wrote:
> > On 2013年07月08日 7:19 PM, Tony Yu wrote:
> >> This is an idea that's been kicking around in my head for awhile.
> >> Basically, the Axes class is way too expansive. Nelle made a major step
> >> in the right direction with a PR that split it up into plotting and
> >> non-plotting methods:
> >>
> >> https://github.com/matplotlib/matplotlib/pull/1931/files
> >>
> >> What I'd like to see is something that further separates plotting
> >> methods into many smaller sub-modules/-packages. Organizing the code
> >> this way would make it easier (for me at least) to read, understand, and
> >> make changes to the code.
> >>
> >> I think that this could be done in an API-compatible way. In fact, a few
> >> of the plotting methods are already implemented this way: In other
> >> words, the bulk of the methods are implemented as functions outside of
> >> Axes, and the Axes methods that are just thin wrappers around those
> >> functions (or classes). See, for example, `streamplot`, `barbs`, and
> >> `quiver` methods
> >
> > I agree. I would like to see logical groups of plot types broken out
> > into modules.
>
> That's the second step in the refactoring of the axes module.
> We now have to discuss how to organize plots in subtypes that make
> sense. At Scipy, we discussed a bit about it, and we think it should
> follow the same organization as the gallery, but I don't know whether
> the gallery reorganization is logical enough right now to start the
> refactoring straight away.
>
> Should we discuss about this here, or in a ticket?
>
> >>
> >> The examples mentioned above simply take the axes as the first
> >> parameter. Here's the Axes-method definition of `quiver`, for example:
> >>
> >> def quiver(self, *args, **kw):
> >> ...
> >> q = mquiver.Quiver(self, *args, **kw)
> >> ...
> >> return q
> >>
> >> (might be a good idea to add a decorator to maintain the function
> >> signature and docstring)
> >>
> >> This should work for any of the plotting methods (I would imagine).
> >> Another alternative is for all these plotting functions to have an `ax`
> >> (or some other spelling) keyword argument that defaults to None and then
> >> have a line in every function that does something like
> >>
> >> ax = ax if ax is not None else plt.gca()
> >>
> >> If I'm not mistaken, this would allow pyplot functions to be even
> >> thinner wrappers around these newly extracted functions. (In some cases,
> >> it might just be a simple import from the the new sub-package/-module
> >> into the `pyplot` namespace).
> >>
> >
> > This would require pyplot to be imported by everything, wouldn't it?
> > That would completely defeat the strategy of having an OO level that
> > doesn't know about pyplot at all, and then having pyplot be the thin top
> > layer.
> >
> > Eric
> >
> >> I haven't sat down and thought through all the details of such a change,
> >> but I wanted to throw it out there to see if anything sticks.
> >>
> >> Cheers,
> >> -Tony
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> See everything from the browser to the database with AppDynamics
> >> Get end-to-end visibility with application monitoring from AppDynamics
> >> Isolate bottlenecks and diagnose root cause in seconds.
> >> Start your free trial of AppDynamics Pro today!
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> >>
> >>
> >>
> >> _______________________________________________
> >> Matplotlib-devel mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> 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 9 July 2013 08:24, Eric Firing <ef...@ha...> wrote:
> On 2013年07月08日 7:19 PM, Tony Yu wrote:
>> This is an idea that's been kicking around in my head for awhile.
>> Basically, the Axes class is way too expansive. Nelle made a major step
>> in the right direction with a PR that split it up into plotting and
>> non-plotting methods:
>>
>> https://github.com/matplotlib/matplotlib/pull/1931/files
>>
>> What I'd like to see is something that further separates plotting
>> methods into many smaller sub-modules/-packages. Organizing the code
>> this way would make it easier (for me at least) to read, understand, and
>> make changes to the code.
>>
>> I think that this could be done in an API-compatible way. In fact, a few
>> of the plotting methods are already implemented this way: In other
>> words, the bulk of the methods are implemented as functions outside of
>> Axes, and the Axes methods that are just thin wrappers around those
>> functions (or classes). See, for example, `streamplot`, `barbs`, and
>> `quiver` methods
>
> I agree. I would like to see logical groups of plot types broken out
> into modules.
That's the second step in the refactoring of the axes module.
We now have to discuss how to organize plots in subtypes that make
sense. At Scipy, we discussed a bit about it, and we think it should
follow the same organization as the gallery, but I don't know whether
the gallery reorganization is logical enough right now to start the
refactoring straight away.
Should we discuss about this here, or in a ticket?
>>
>> The examples mentioned above simply take the axes as the first
>> parameter. Here's the Axes-method definition of `quiver`, for example:
>>
>> def quiver(self, *args, **kw):
>> ...
>> q = mquiver.Quiver(self, *args, **kw)
>> ...
>> return q
>>
>> (might be a good idea to add a decorator to maintain the function
>> signature and docstring)
>>
>> This should work for any of the plotting methods (I would imagine).
>> Another alternative is for all these plotting functions to have an `ax`
>> (or some other spelling) keyword argument that defaults to None and then
>> have a line in every function that does something like
>>
>> ax = ax if ax is not None else plt.gca()
>>
>> If I'm not mistaken, this would allow pyplot functions to be even
>> thinner wrappers around these newly extracted functions. (In some cases,
>> it might just be a simple import from the the new sub-package/-module
>> into the `pyplot` namespace).
>>
>
> This would require pyplot to be imported by everything, wouldn't it?
> That would completely defeat the strategy of having an OO level that
> doesn't know about pyplot at all, and then having pyplot be the thin top
> layer.
>
> Eric
>
>> I haven't sat down and thought through all the details of such a change,
>> but I wanted to throw it out there to see if anything sticks.
>>
>> Cheers,
>> -Tony
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 2013年07月08日 7:19 PM, Tony Yu wrote:
> This is an idea that's been kicking around in my head for awhile.
> Basically, the Axes class is way too expansive. Nelle made a major step
> in the right direction with a PR that split it up into plotting and
> non-plotting methods:
>
> https://github.com/matplotlib/matplotlib/pull/1931/files
>
> What I'd like to see is something that further separates plotting
> methods into many smaller sub-modules/-packages. Organizing the code
> this way would make it easier (for me at least) to read, understand, and
> make changes to the code.
>
> I think that this could be done in an API-compatible way. In fact, a few
> of the plotting methods are already implemented this way: In other
> words, the bulk of the methods are implemented as functions outside of
> Axes, and the Axes methods that are just thin wrappers around those
> functions (or classes). See, for example, `streamplot`, `barbs`, and
> `quiver` methods
I agree. I would like to see logical groups of plot types broken out 
into modules.
>
> The examples mentioned above simply take the axes as the first
> parameter. Here's the Axes-method definition of `quiver`, for example:
>
> def quiver(self, *args, **kw):
> ...
> q = mquiver.Quiver(self, *args, **kw)
> ...
> return q
>
> (might be a good idea to add a decorator to maintain the function
> signature and docstring)
>
> This should work for any of the plotting methods (I would imagine).
> Another alternative is for all these plotting functions to have an `ax`
> (or some other spelling) keyword argument that defaults to None and then
> have a line in every function that does something like
>
> ax = ax if ax is not None else plt.gca()
>
> If I'm not mistaken, this would allow pyplot functions to be even
> thinner wrappers around these newly extracted functions. (In some cases,
> it might just be a simple import from the the new sub-package/-module
> into the `pyplot` namespace).
>
This would require pyplot to be imported by everything, wouldn't it? 
That would completely defeat the strategy of having an OO level that 
doesn't know about pyplot at all, and then having pyplot be the thin top 
layer.
Eric
> I haven't sat down and thought through all the details of such a change,
> but I wanted to throw it out there to see if anything sticks.
>
> Cheers,
> -Tony
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

This is an idea that's been kicking around in my head for awhile.
Basically, the Axes class is way too expansive. Nelle made a major step in
the right direction with a PR that split it up into plotting and
non-plotting methods:
https://github.com/matplotlib/matplotlib/pull/1931/files
What I'd like to see is something that further separates plotting methods
into many smaller sub-modules/-packages. Organizing the code this way would
make it easier (for me at least) to read, understand, and make changes to
the code.
I think that this could be done in an API-compatible way. In fact, a few of
the plotting methods are already implemented this way: In other words, the
bulk of the methods are implemented as functions outside of Axes, and the
Axes methods that are just thin wrappers around those functions (or
classes). See, for example, `streamplot`, `barbs`, and `quiver` methods
The examples mentioned above simply take the axes as the first parameter.
Here's the Axes-method definition of `quiver`, for example:
 def quiver(self, *args, **kw):
 ...
 q = mquiver.Quiver(self, *args, **kw)
 ...
 return q
(might be a good idea to add a decorator to maintain the function signature
and docstring)
This should work for any of the plotting methods (I would imagine). Another
alternative is for all these plotting functions to have an `ax` (or some
other spelling) keyword argument that defaults to None and then have a line
in every function that does something like
 ax = ax if ax is not None else plt.gca()
If I'm not mistaken, this would allow pyplot functions to be even thinner
wrappers around these newly extracted functions. (In some cases, it might
just be a simple import from the the new sub-package/-module into the
`pyplot` namespace).
I haven't sat down and thought through all the details of such a change,
but I wanted to throw it out there to see if anything sticks.
Cheers,
-Tony

Hi
Thank you that solves the problem we had.
I'm sorry for posting this on the development list, it was intended for the
users list, and I somehow entered the wrong address.
Regards
Pål
On 7 July 2013 21:44, Eric Firing <ef...@ha...> wrote:
> On 2013年07月04日 11:43 PM, Pål Gunnar Ellingsen wrote:
> > Hi
> >
> > I'm having some problems with the formatter of ticks in a polar plot.
> > Below is a minimum example
> > The first figure is correct, the second has wrong ticks.
> >
> > This has be tested both on 1.2.0 and the latest from git (1.4.x, commit
> > 64cc3416396ffb2811af80fc810ed63572df71d9 )
> >
> > Does anyone know whys this happens?
> > Is it a bug in MaxNLocator
>
> No, it is a misunderstanding of how the colorbar works. It's long axis
> is using its own units, and it maps the color scale to those units.
> Therefore, one should not try to manipulate the axis properties
> directly. Below I show two altered lines and one deletion. I think
> this will produce what you want.
>
> >
> > Kind regards
> >
> > Pål
> >
> > ---------------------------
> > #!/usr/bin/env python
> >
> > import numpy as np
> > import matplotlib.pyplot as plt
> > from matplotlib.ticker import MaxNLocator
> >
> > # Data
> > M=np.sin(np.meshgrid(np.arange(30),np.arange(30)))
> > M=np.squeeze(M[0,:,:])
> > Radius=np.arange(30)
> > Theta=np.arange(30)
> >
> > # Plotting the correct figure
> > print('Correct ticks')
> > fig=plt.figure()
> > ax1 = fig.add_axes([0,0,0.8,1],projection='polar')
> > c = ax1.pcolormesh(Theta, Radius, M)
> > ax1.set_frame_on(False)
> > plt.xticks([])
> > plt.yticks([])
> > ax2=fig.add_axes([0.9,0.1,0.05,0.7])
> > cb=fig.colorbar(c,cax=ax2)
> > plt.show()
> >
> > # Doing the same plot
> > print('Wrong ticks by using formatter')
> > fig=plt.figure()
> > ax1 = fig.add_axes([0,0,0.8,1],projection='polar')
> #> c = ax1.pcolormesh(Theta, Radius, M)
>
> c = ax1.pcolormesh(Theta, Radius, M, vmin=-1, vmax=1)
>
> > ax1.set_frame_on(False)
> > plt.xticks([])
> > plt.yticks([])
> > ax2=fig.add_axes([0.9,0.1,0.05,0.7])
> #> cb=fig.colorbar(c,cax=ax2)
>
> cb = fig.colorbar(c, cax=ax2, ticks=MaxNLocator(3))
>
> >
> #> # except now setting a limit to the number of ticks using a formatter
> #> # which results in wrong ticks
> #> cb.ax.yaxis.set_major_locator(MaxNLocator(3))
>
> > plt.show()
>
> Eric
>
> > -----------------------
> >
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Windows:
> >
> > Build for Windows Store.
> >
> > http://p.sf.net/sfu/windows-dev2dev
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Sun, Jul 7, 2013 at 10:14 PM, Tony Yu <ts...@gm...> wrote:
> Hi David,
>
> Sorry for the delay in replying. It was good meeting you last week.
> Comments inline with a lot of parts cut out.
>
Hi Tony,
It was great to meet you too!
>
>
> On Thu, Jul 4, 2013 at 10:13 PM, David P. Sanders <dps...@gm...>wrote:
>>
>> I have been working, as a first step, on colored line support. This is
>> not, of course, new -- it's all in LineCollection. However, as a user,
>> LineCollection is intimidating and difficult to understand, and does not
>> lead to easy experimentation (I speak from experience).
>>
>
> I agree that LineCollection isn't the most user-friendly thing to use.
> Personally, I'd be in favor of something like your `linecolor` suggestion,
> but I'd understand if the core-devs have concerns about feature creep.
>
Yes, I do understand your point, but I feel strongly that providing simple
interfaces for otherwise complicated concepts / syntax is important, and
very much in the spirit of matplotlib as I understand it.
>
>
>> At Tony's suggestion, the first step was to rewrite the
>> multicolored_line.py example.
>> You can find my first attempt as an IPython notebook at
>>
>>
>> https://github.com/dpsanders/matplotlib-examples/blob/master/linecolor.ipynb
>>
>> or
>>
>>
>> http://nbviewer.ipython.org/urls/raw.github.com/dpsanders/matplotlib-examples/master/linecolor.ipynb
>>
>
> This looked pretty interesting when I first looked at it, but it seems to
> be down now.
>
Apologies, I decided that 'colorline' was a better name than 'linecolor'
(since 'colorline' suggests that we are going to color a line, i.e. it puts
the verb and the noun in the correct order!), so I changed the notebook to
https://github.com/dpsanders/matplotlib-examples/blob/master/colorline.ipynb
http://nbviewer.ipython.org/urls/raw.github.com/dpsanders/matplotlib-examples/master/colorline.ipynb
>
>
>> Please let me have any comments before I attempt the next step of making
>> a pull request.
>>
>
I am trying to get to making a pull request, but am having trouble
incorporating the plot correctly into the gallery:
I have been trying to include colorline.py in the correct place in the
examples tree to have it added automatically to the gallery.
Somebody (don't remember who exactly -- Mike?) showed me how to do this
during the sprint, but I have been unable to reproduce the steps
successfully.
Could you please remind me exactly where I should put the file, and what
the correct sequence of commands to execute is? Is there a special format
that the file should have? For example, it seems that it should only have
one plt.show() following the other examples with multiple plots -- is
that right?
(I once managed to get a single one of the plots to show in the gallery,
and have not been able to reproduce that feat since!)
> It seems to me that IPython notebooks are quite a natural format for
>> such examples, especially with a view to having interactive examples in the
>> future.
>>
>
> Using IPython notebooks as examples would be really beneficial in the long
> run, as discussed during the BoF. I struggled with implementing support for
> interleaved text, code, and plots for the scikit-image gallery (so that
> examples could have real explanations). IPython notebooks are a more
> natural format for this, but they're not quite there yet---specifically
> nbconvert is still evolving (though this should be integrated into the next
> release). That said, someone will need to write the code that takes the
> output from nbconvert and integrates it with the current Sphinx code that
> generates the gallery. Most of this will be straightforward but tedious.
>
The current git master of ipython indeed has nbconvert integrated. The
Python script output is also in my git repository -- these kind of outputs
should be easy to parse.
(Though I personally have no idea where to even start with something like
that. Any suggestions? Is there some kind of standard package for this kind
of thing?)
>
>
>> What is the situation with tagging the examples? If the examples are
>> being refactored, it would seem to at least be a natural moment to start
>> adding tags, even if nothing is actually done with them yet.
>>
>
> This is a great idea. I wish I had suggested this in my original MEP. I'm
> not sure if there's been progress on adding an interface for tags, but we
> should be adding tags during any clean ups to the examples so they're ready
> in the
>
I agree that it should be added to the MEP. From my point of view, the
exact tags that should be used may well be something that evolves over time.
>
> - Also during the BoF / sprint, style sheets were discussed several times.
>> Tony seems to have already solved this problem in his mpltools package --
>> I would suggest that this could be brought straight into Matplotlib?
>>
>
> This was my original plan. At the time I wrote the original, the rc parser
> wasn't exposed to the user. That's been fixed now, but I haven't found the
> time to integrate changes into Matplotlib proper. If anyone else would like
> to have a go at it, they are more than welcome. Otherwise, I'll get to it
> at some point ... hopefully.
>
OK, great.
Best,
David.
>
> Cheers!
> -Tony
>
-- 
**************************************************************************
Dr. David P. Sanders
Profesor Titular A / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)
dps...@gm...
http://sistemas.fciencias.unam.mx/~dsanders
Cubículo / office: #414
Tel.: +52 55 5622 4965

Hi David,
Sorry for the delay in replying. It was good meeting you last week.
Comments inline with a lot of parts cut out.
On Thu, Jul 4, 2013 at 10:13 PM, David P. Sanders <dps...@gm...>wrote:
>
> I have been working, as a first step, on colored line support. This is
> not, of course, new -- it's all in LineCollection. However, as a user,
> LineCollection is intimidating and difficult to understand, and does not
> lead to easy experimentation (I speak from experience).
>
I agree that LineCollection isn't the most user-friendly thing to use.
Personally, I'd be in favor of something like your `linecolor` suggestion,
but I'd understand if the core-devs have concerns about feature creep.
> At Tony's suggestion, the first step was to rewrite the
> multicolored_line.py example.
> You can find my first attempt as an IPython notebook at
>
>
> https://github.com/dpsanders/matplotlib-examples/blob/master/linecolor.ipynb
>
> or
>
>
> http://nbviewer.ipython.org/urls/raw.github.com/dpsanders/matplotlib-examples/master/linecolor.ipynb
>
This looked pretty interesting when I first looked at it, but it seems to
be down now.
> Please let me have any comments before I attempt the next step of making a
> pull request.
> It seems to me that IPython notebooks are quite a natural format for such
> examples, especially with a view to having interactive examples in the
> future.
>
Using IPython notebooks as examples would be really beneficial in the long
run, as discussed during the BoF. I struggled with implementing support for
interleaved text, code, and plots for the scikit-image gallery (so that
examples could have real explanations). IPython notebooks are a more
natural format for this, but they're not quite there yet---specifically
nbconvert is still evolving (though this should be integrated into the next
release). That said, someone will need to write the code that takes the
output from nbconvert and integrates it with the current Sphinx code that
generates the gallery. Most of this will be straightforward but tedious.
> What is the situation with tagging the examples? If the examples are being
> refactored, it would seem to at least be a natural moment to start adding
> tags, even if nothing is actually done with them yet.
>
This is a great idea. I wish I had suggested this in my original MEP. I'm
not sure if there's been progress on adding an interface for tags, but we
should be adding tags during any clean ups to the examples so they're ready
in the future.
- Also during the BoF / sprint, style sheets were discussed several times.
> Tony seems to have already solved this problem in his mpltools package --
> I would suggest that this could be brought straight into Matplotlib?
>
This was my original plan. At the time I wrote the original, the rc parser
wasn't exposed to the user. That's been fixed now, but I haven't found the
time to integrate changes into Matplotlib proper. If anyone else would like
to have a go at it, they are more than welcome. Otherwise, I'll get to it
at some point ... hopefully.
Cheers!
-Tony

On 2013年07月04日 11:43 PM, Pål Gunnar Ellingsen wrote:
> Hi
>
> I'm having some problems with the formatter of ticks in a polar plot.
> Below is a minimum example
> The first figure is correct, the second has wrong ticks.
>
> This has be tested both on 1.2.0 and the latest from git (1.4.x, commit
> 64cc3416396ffb2811af80fc810ed63572df71d9 )
>
> Does anyone know whys this happens?
> Is it a bug in MaxNLocator
No, it is a misunderstanding of how the colorbar works. It's long axis 
is using its own units, and it maps the color scale to those units. 
Therefore, one should not try to manipulate the axis properties 
directly. Below I show two altered lines and one deletion. I think 
this will produce what you want.
>
> Kind regards
>
> Pål
>
> ---------------------------
> #!/usr/bin/env python
>
> import numpy as np
> import matplotlib.pyplot as plt
> from matplotlib.ticker import MaxNLocator
>
> # Data
> M=np.sin(np.meshgrid(np.arange(30),np.arange(30)))
> M=np.squeeze(M[0,:,:])
> Radius=np.arange(30)
> Theta=np.arange(30)
>
> # Plotting the correct figure
> print('Correct ticks')
> fig=plt.figure()
> ax1 = fig.add_axes([0,0,0.8,1],projection='polar')
> c = ax1.pcolormesh(Theta, Radius, M)
> ax1.set_frame_on(False)
> plt.xticks([])
> plt.yticks([])
> ax2=fig.add_axes([0.9,0.1,0.05,0.7])
> cb=fig.colorbar(c,cax=ax2)
> plt.show()
>
> # Doing the same plot
> print('Wrong ticks by using formatter')
> fig=plt.figure()
> ax1 = fig.add_axes([0,0,0.8,1],projection='polar')
#> c = ax1.pcolormesh(Theta, Radius, M)
c = ax1.pcolormesh(Theta, Radius, M, vmin=-1, vmax=1)
> ax1.set_frame_on(False)
> plt.xticks([])
> plt.yticks([])
> ax2=fig.add_axes([0.9,0.1,0.05,0.7])
#> cb=fig.colorbar(c,cax=ax2)
cb = fig.colorbar(c, cax=ax2, ticks=MaxNLocator(3))
>
#> # except now setting a limit to the number of ticks using a formatter
#> # which results in wrong ticks
#> cb.ax.yaxis.set_major_locator(MaxNLocator(3))
> plt.show()
Eric
> -----------------------
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

> Thomas Kluyver <mailto:th...@kl...>
> July 6, 2013 11:26 AM
>
> *distribute*, which was a fork of setuptools, was merged into 
> setuptools. *distutils* is the component in the standard library, and 
> is still there. I still prefer distutils where possible, precisely 
> because setuptools' eggs are a mess.
>
> Thomas
I agree eggs are a mess. Given that it is still easy to have the old 
behavior, can someone explain why the change was made to have setup.py 
create eggs by default?
-Jeff
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> Damon McDougall <mailto:dam...@gm...>
> July 6, 2013 11:20 AM
>
>
>
> On Sat, Jul 6, 2013 at 11:04 AM, Jeff Whitaker <js...@fa... 
> <mailto:js...@fa...>> wrote:
>
>> Damon McDougall <mailto:dam...@gm...>
>> July 6, 2013 9:32 AM
>>
>>
>>
>> If I do a clean install of mpl master, and then of basemap,
>> basemap
>> lands in dist-packages/mpl_toolkits, as it always has. But
>> now it is
>> not found--I can't import it. It seems that now the *real*
>> mpl_toolkits
>> is cleverly hidden inside an egg directory with a monstrous name,
>> leaving basemap orphaned in a directory with no __init__.py.
>> As a
>> workaround I can symlink it into the egg location. I suspect
>> the real
>> solution will require basemap to use setuptools, correct? I
>> don't know
>> how to do this, so I hope someone who does will submit a PR.
>>
>>
>> Actually, using the new setuptools isn't adequate, I just tried
>> it locally on my machine and it still doesn't install itself into
>> the matplotlib egg.
>>
>> I think the proper solution here is to add basemap as an optional
>> dependency to matplotlib and have the user set a flag (off by
>> default) to pull basemap if it's desired
>>
>> Does that sound like a reasonable solution?
>
> What if a user decides later that he/she wants to install
> basemap? Then they would have to reinstall matplotlib? That
> doesn't sound reasonable to me.
>
>
> Actually, on reflection, I'm in agreement with you. I'm comfortable 
> installing from source but this poses a larger problem when users 
> download the basemap binary and expect it to Just Work.
>
> How about having matplotlib install a symlink to the egg location?
>
>
> If there's a way for setuptools to modify the matplotlib egg to add a 
> symlink, then it must be possible for setuptools to just put the files 
> there. I just haven't figured out how to do that.
>
> Why the change to using setuptools by default in the first place?
>
>
> Long story. The short story is that distutils was merged into 
> setuptools. So setuptools is now the recommended way to install 
> python packages.
>
>
> -Jeff
>>
>> P.S. Note that the other mpl_toolkits are installed into the
>> correct place because they are shipped with matplotlib and
>> installed at the same time. We could ship basemap with
>> matplotlib too but it's a rather large download.
>>
>> 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
>> Eric Firing <mailto:ef...@ha...>
>> July 6, 2013 12:53 AM
>> If I do a clean install of mpl master, and then of basemap,
>> basemap lands in dist-packages/mpl_toolkits, as it always has. 
>> But now it is not found--I can't import it. It seems that now
>> the *real* mpl_toolkits is cleverly hidden inside an egg
>> directory with a monstrous name, leaving basemap orphaned in a
>> directory with no __init__.py. As a workaround I can symlink it
>> into the egg location. I suspect the real solution will require
>> basemap to use setuptools, correct? I don't know how to do this,
>> so I hope someone who does will submit a PR.
>>
>> Eric
>>
>> ------------------------------------------------------------------------
>
>
>
>
> -- 
> 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
> Jeff Whitaker <mailto:js...@fa...>
> July 6, 2013 10:04 AM
>> Damon McDougall <mailto:dam...@gm...>
>> July 6, 2013 9:32 AM
>>
>>
>>
>> If I do a clean install of mpl master, and then of basemap, basemap
>> lands in dist-packages/mpl_toolkits, as it always has. But now it is
>> not found--I can't import it. It seems that now the *real*
>> mpl_toolkits
>> is cleverly hidden inside an egg directory with a monstrous name,
>> leaving basemap orphaned in a directory with no __init__.py. As a
>> workaround I can symlink it into the egg location. I suspect the
>> real
>> solution will require basemap to use setuptools, correct? I
>> don't know
>> how to do this, so I hope someone who does will submit a PR.
>>
>>
>> Actually, using the new setuptools isn't adequate, I just tried it 
>> locally on my machine and it still doesn't install itself into the 
>> matplotlib egg.
>>
>> I think the proper solution here is to add basemap as an optional 
>> dependency to matplotlib and have the user set a flag (off by 
>> default) to pull basemap if it's desired
>>
>> Does that sound like a reasonable solution?
>
> What if a user decides later that he/she wants to install basemap? 
> Then they would have to reinstall matplotlib? That doesn't sound 
> reasonable to me.
>
> How about having matplotlib install a symlink to the egg location?
>
> Why the change to using setuptools by default in the first place?
>
> -Jeff
>>
>> P.S. Note that the other mpl_toolkits are installed into the correct 
>> place because they are shipped with matplotlib and installed at the 
>> same time. We could ship basemap with matplotlib too but it's a 
>> rather large download.
>>
>> 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
>> Eric Firing <mailto:ef...@ha...>
>> July 6, 2013 12:53 AM
>> If I do a clean install of mpl master, and then of basemap, basemap 
>> lands in dist-packages/mpl_toolkits, as it always has. But now it is 
>> not found--I can't import it. It seems that now the *real* 
>> mpl_toolkits is cleverly hidden inside an egg directory with a 
>> monstrous name, leaving basemap orphaned in a directory with no 
>> __init__.py. As a workaround I can symlink it into the egg 
>> location. I suspect the real solution will require basemap to use 
>> setuptools, correct? I don't know how to do this, so I hope someone 
>> who does will submit a PR.
>>
>> Eric
>>
>> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> Damon McDougall <mailto:dam...@gm...>
> July 6, 2013 9:32 AM
>
>
>
> If I do a clean install of mpl master, and then of basemap, basemap
> lands in dist-packages/mpl_toolkits, as it always has. But now it is
> not found--I can't import it. It seems that now the *real*
> mpl_toolkits
> is cleverly hidden inside an egg directory with a monstrous name,
> leaving basemap orphaned in a directory with no __init__.py. As a
> workaround I can symlink it into the egg location. I suspect the real
> solution will require basemap to use setuptools, correct? I don't
> know
> how to do this, so I hope someone who does will submit a PR.
>
>
> Actually, using the new setuptools isn't adequate, I just tried it 
> locally on my machine and it still doesn't install itself into the 
> matplotlib egg.
>
> I think the proper solution here is to add basemap as an optional 
> dependency to matplotlib and have the user set a flag (off by default) 
> to pull basemap if it's desired.
>
> Does that sound like a reasonable solution?
>
> P.S. Note that the other mpl_toolkits are installed into the correct 
> place because they are shipped with matplotlib and installed at the 
> same time. We could ship basemap with matplotlib too but it's a 
> rather large download.
>
> 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
> Eric Firing <mailto:ef...@ha...>
> July 6, 2013 12:53 AM
> If I do a clean install of mpl master, and then of basemap, basemap 
> lands in dist-packages/mpl_toolkits, as it always has. But now it is 
> not found--I can't import it. It seems that now the *real* 
> mpl_toolkits is cleverly hidden inside an egg directory with a 
> monstrous name, leaving basemap orphaned in a directory with no 
> __init__.py. As a workaround I can symlink it into the egg location. 
> I suspect the real solution will require basemap to use setuptools, 
> correct? I don't know how to do this, so I hope someone who does will 
> submit a PR.
>
> Eric
>
> ------------------------------------------------------------------------

On Sat, Jul 6, 2013 at 12:20 PM, Eric Firing <ef...@ha...> wrote:
> On 2013年07月06日 5:32 AM, Damon McDougall wrote:
>
>>
>>
>>
>> On Sat, Jul 6, 2013 at 1:53 AM, Eric Firing <ef...@ha...
>> <mailto:ef...@ha...>> wrote:
>>
>> If I do a clean install of mpl master, and then of basemap, basemap
>> lands in dist-packages/mpl_toolkits, as it always has. But now it is
>> not found--I can't import it. It seems that now the *real*
>> mpl_toolkits
>> is cleverly hidden inside an egg directory with a monstrous name,
>> leaving basemap orphaned in a directory with no __init__.py. As a
>> workaround I can symlink it into the egg location. I suspect the real
>> solution will require basemap to use setuptools, correct? I don't
>> know
>> how to do this, so I hope someone who does will submit a PR.
>>
>>
>> Actually, using the new setuptools isn't adequate, I just tried it
>> locally on my machine and it still doesn't install itself into the
>> matplotlib egg.
>>
>
> Thank you for giving it a try.
No worries. All I did was use matplotlib's distribute_setup.py file and
add the lines
from distribute_setup import use_setuptools
use_setuptools()
to setup.py.
I'm sure there's extra setuptools foo I need to make it play nicely with
the matplotlib egg, but I haven't at all looked into it in any detail.
>
>
>
>> I think the proper solution here is to add basemap as an optional
>> dependency to matplotlib and have the user set a flag (off by default)
>> to pull basemap if it's desired.
>>
>> Does that sound like a reasonable solution?
>>
>
> No, unfortunately. First, because fundamentally, matplotlib is a
> dependency of basemap, not the other way around. Second, because I want to
> be able to pull basemap from git and do the usual "setup.py build, setup.py
> install" independently of matplotlib.
>
Ah yes, that's entirely reasonable.
>
> It sounds like the only real solution will be for basemap to live as an
> independent package in dist-packages, and drop the mpl_toolkits umbrella
> entirely. I don't see that it does any good anyway. It seems setuptools
> has irretrievably broken the usefulness of mpl_toolkits as anything other
> than a place to put sub-packages that are distributed with mpl, and that
> live in the same git repo.
>
That's sounds reasonable to me. But there's a part of me that can't help
thinking that what we're trying to do should be entirely possible. Perhaps
it's more hacky, though.
>
> Moving basemap out of mpl_toolkits would also simplify the basemap
> directory structure. I don't see any downside other than the pain of the
> transition itself, including the problem of user code needing to have every
> import of basemap handle both possible locations.
>
I'm not against having it as a separate package. We can deprecate the old
location and remove it in 1.5.x, say.
>
> The setuptools arrangement of having mpl_toolkits hidden in an egg, but
> still imported as "import mpl_toolkits", seems like a horrible design. I'm
> also uncomfortable with the new behavior in which the standard command to
> build and install mpl triggers an avalanche of potential package
> installations. Oh, well...
Yes, I know. It's a mess. Also notice that it's really hard to downgrade
to maptlotlib version 1.3.x after having installed 1.4.x, because
setuptools creates an egg for each version. In principle this is nice as,
I assume, it offers the flexibility to switch between different matplotlib
versions on the fly. That said, I see no way to actually do this.
>
>
> Eric
>
>
>
>> P.S. Note that the other mpl_toolkits are installed into the correct
>> place because they are shipped with matplotlib and installed at the same
>> time. We could ship basemap with matplotlib too but it's a rather large
>> download.
>>
>> 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
>>
>
>
-- 
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 Sat, Jul 6, 2013 at 12:26 PM, Thomas Kluyver <th...@kl...>wrote:
> On 6 July 2013 18:20, Damon McDougall <dam...@gm...> wrote:
>
>> Long story. The short story is that distutils was merged into
>> setuptools. So setuptools is now the recommended way to install python
>> packages.
>
>
> *distribute*, which was a fork of setuptools, was merged into setuptools.
> *distutils* is the component in the standard library, and is still there. I
> still prefer distutils where possible, precisely because setuptools' eggs
> are a mess.
>
Sorry, yes. My mistake.
>
>
> Thomas
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> 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

On 6 July 2013 18:20, Damon McDougall <dam...@gm...> wrote:
> Long story. The short story is that distutils was merged into setuptools.
> So setuptools is now the recommended way to install python packages.
*distribute*, which was a fork of setuptools, was merged into setuptools.
*distutils* is the component in the standard library, and is still there. I
still prefer distutils where possible, precisely because setuptools' eggs
are a mess.
Thomas

On 2013年07月06日 5:32 AM, Damon McDougall wrote:
>
>
>
> On Sat, Jul 6, 2013 at 1:53 AM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
> If I do a clean install of mpl master, and then of basemap, basemap
> lands in dist-packages/mpl_toolkits, as it always has. But now it is
> not found--I can't import it. It seems that now the *real* mpl_toolkits
> is cleverly hidden inside an egg directory with a monstrous name,
> leaving basemap orphaned in a directory with no __init__.py. As a
> workaround I can symlink it into the egg location. I suspect the real
> solution will require basemap to use setuptools, correct? I don't know
> how to do this, so I hope someone who does will submit a PR.
>
>
> Actually, using the new setuptools isn't adequate, I just tried it
> locally on my machine and it still doesn't install itself into the
> matplotlib egg.
Thank you for giving it a try.
>
> I think the proper solution here is to add basemap as an optional
> dependency to matplotlib and have the user set a flag (off by default)
> to pull basemap if it's desired.
>
> Does that sound like a reasonable solution?
No, unfortunately. First, because fundamentally, matplotlib is a 
dependency of basemap, not the other way around. Second, because I want 
to be able to pull basemap from git and do the usual "setup.py build, 
setup.py install" independently of matplotlib.
It sounds like the only real solution will be for basemap to live as an 
independent package in dist-packages, and drop the mpl_toolkits umbrella 
entirely. I don't see that it does any good anyway. It seems 
setuptools has irretrievably broken the usefulness of mpl_toolkits as 
anything other than a place to put sub-packages that are distributed 
with mpl, and that live in the same git repo.
Moving basemap out of mpl_toolkits would also simplify the basemap 
directory structure. I don't see any downside other than the pain of 
the transition itself, including the problem of user code needing to 
have every import of basemap handle both possible locations.
The setuptools arrangement of having mpl_toolkits hidden in an egg, but 
still imported as "import mpl_toolkits", seems like a horrible design. 
I'm also uncomfortable with the new behavior in which the standard 
command to build and install mpl triggers an avalanche of potential 
package installations. Oh, well...
Eric
>
> P.S. Note that the other mpl_toolkits are installed into the correct
> place because they are shipped with matplotlib and installed at the same
> time. We could ship basemap with matplotlib too but it's a rather large
> download.
>
> 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

> Damon McDougall <mailto:dam...@gm...>
> July 6, 2013 9:32 AM
>
>
>
> If I do a clean install of mpl master, and then of basemap, basemap
> lands in dist-packages/mpl_toolkits, as it always has. But now it is
> not found--I can't import it. It seems that now the *real*
> mpl_toolkits
> is cleverly hidden inside an egg directory with a monstrous name,
> leaving basemap orphaned in a directory with no __init__.py. As a
> workaround I can symlink it into the egg location. I suspect the real
> solution will require basemap to use setuptools, correct? I don't
> know
> how to do this, so I hope someone who does will submit a PR.
>
>
> Actually, using the new setuptools isn't adequate, I just tried it 
> locally on my machine and it still doesn't install itself into the 
> matplotlib egg.
>
> I think the proper solution here is to add basemap as an optional 
> dependency to matplotlib and have the user set a flag (off by default) 
> to pull basemap if it's desired
>
> Does that sound like a reasonable solution?
What if a user decides later that he/she wants to install basemap? Then 
they would have to reinstall matplotlib? That doesn't sound reasonable 
to me.
How about having matplotlib install a symlink to the egg location?
Why the change to using setuptools by default in the first place?
-Jeff
>
> P.S. Note that the other mpl_toolkits are installed into the correct 
> place because they are shipped with matplotlib and installed at the 
> same time. We could ship basemap with matplotlib too but it's a 
> rather large download.
>
> 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
> Eric Firing <mailto:ef...@ha...>
> July 6, 2013 12:53 AM
> If I do a clean install of mpl master, and then of basemap, basemap 
> lands in dist-packages/mpl_toolkits, as it always has. But now it is 
> not found--I can't import it. It seems that now the *real* 
> mpl_toolkits is cleverly hidden inside an egg directory with a 
> monstrous name, leaving basemap orphaned in a directory with no 
> __init__.py. As a workaround I can symlink it into the egg location. 
> I suspect the real solution will require basemap to use setuptools, 
> correct? I don't know how to do this, so I hope someone who does will 
> submit a PR.
>
> Eric
>
> ------------------------------------------------------------------------

On Sat, Jul 6, 2013 at 1:53 AM, Eric Firing <ef...@ha...> wrote:
> If I do a clean install of mpl master, and then of basemap, basemap
> lands in dist-packages/mpl_toolkits, as it always has. But now it is
> not found--I can't import it. It seems that now the *real* mpl_toolkits
> is cleverly hidden inside an egg directory with a monstrous name,
> leaving basemap orphaned in a directory with no __init__.py. As a
> workaround I can symlink it into the egg location. I suspect the real
> solution will require basemap to use setuptools, correct? I don't know
> how to do this, so I hope someone who does will submit a PR.
Actually, using the new setuptools isn't adequate, I just tried it locally
on my machine and it still doesn't install itself into the matplotlib egg.
I think the proper solution here is to add basemap as an optional
dependency to matplotlib and have the user set a flag (off by default) to
pull basemap if it's desired.
Does that sound like a reasonable solution?
P.S. Note that the other mpl_toolkits are installed into the correct place
because they are shipped with matplotlib and installed at the same time.
 We could ship basemap with matplotlib too but it's a rather large download.
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

If I do a clean install of mpl master, and then of basemap, basemap 
lands in dist-packages/mpl_toolkits, as it always has. But now it is 
not found--I can't import it. It seems that now the *real* mpl_toolkits 
is cleverly hidden inside an egg directory with a monstrous name, 
leaving basemap orphaned in a directory with no __init__.py. As a 
workaround I can symlink it into the egg location. I suspect the real 
solution will require basemap to use setuptools, correct? I don't know 
how to do this, so I hope someone who does will submit a PR.
Eric

Hi
I'm having some problems with the formatter of ticks in a polar plot.
Below is a minimum example
The first figure is correct, the second has wrong ticks.
This has be tested both on 1.2.0 and the latest from git (1.4.x, commit
64cc3416396ffb2811af80fc810ed63572df71d9 )
Does anyone know whys this happens?
Is it a bug in MaxNLocator
Kind regards
Pål
---------------------------
#!/usr/bin/env python
import numpy as np
import matplotlib.pyplot as plt
from matplotlib.ticker import MaxNLocator
# Data
M=np.sin(np.meshgrid(np.arange(30),np.arange(30)))
M=np.squeeze(M[0,:,:])
Radius=np.arange(30)
Theta=np.arange(30)
# Plotting the correct figure
print('Correct ticks')
fig=plt.figure()
ax1 = fig.add_axes([0,0,0.8,1],projection='polar')
c = ax1.pcolormesh(Theta, Radius, M)
ax1.set_frame_on(False)
plt.xticks([])
plt.yticks([])
ax2=fig.add_axes([0.9,0.1,0.05,0.7])
cb=fig.colorbar(c,cax=ax2)
plt.show()
# Doing the same plot
print('Wrong ticks by using formatter')
fig=plt.figure()
ax1 = fig.add_axes([0,0,0.8,1],projection='polar')
c = ax1.pcolormesh(Theta, Radius, M)
ax1.set_frame_on(False)
plt.xticks([])
plt.yticks([])
ax2=fig.add_axes([0.9,0.1,0.05,0.7])
cb=fig.colorbar(c,cax=ax2)
# except now setting a limit to the number of ticks using a formatter
# which results in wrong ticks
cb.ax.yaxis.set_major_locator(MaxNLocator(3))
plt.show()
-----------------------

Hi,
It was great to meet many of the Matplotlib developers at SciPy 2013. I had
a great time and I learnt a huge amount, which I am slowly starting to
digest.
In particular, without the Matplotlib sprint, I would never have got off
the ground -- many thanks to all those who took the time to be patient with
me!
I have been working, as a first step, on colored line support. This is not,
of course, new -- it's all in LineCollection. However, as a user,
LineCollection is intimidating and difficult to understand, and does not
lead to easy experimentation (I speak from experience).
At Tony's suggestion, the first step was to rewrite the
multicolored_line.py example.
You can find my first attempt as an IPython notebook at
https://github.com/dpsanders/matplotlib-examples/blob/master/linecolor.ipynb
or
http://nbviewer.ipython.org/urls/raw.github.com/dpsanders/matplotlib-examples/master/linecolor.ipynb
Please let me have any comments before I attempt the next step of making a
pull request.
It seems to me that IPython notebooks are quite a natural format for such
examples, especially with a view to having interactive examples in the
future.
I have tried, as discussed in the sprint, to separate the data processing
from the plotting.
The function "linecolor" (the only other reasonable name that I thought of
was "colorline") should be able to be extracted without too much effort
(hopefully?) into the axes module and into pyplot.
What is the situation with tagging the examples? If the examples are being
refactored, it would seem to at least be a natural moment to start adding
tags, even if nothing is actually done with them yet.
Along these lines, it seems to me that there is a lot of other
functionality which is difficult to get at for the average user who does
not understand collections or patches.
For example, there is an 'arrow' function in pyplot, which just exposes the
FancyArrow patch, but there is no corresponding 'circle', 'ellipse' etc.
function for those patches.
I think this would be a great addition -- what is the general consensus?
By the way, I only understood what an 'axes' object is yesterday, even
though I have been using Matplotlib for several years. The documentation
that I found seems to assume that the user is coming from Matlab and
already implicitly understands what 'axes' refers to.
Some more general comments which I have been led to in this process:
- Ben made the comment that it was very important to have figures in the
documentation for each function. I completely agree with this. It seems to
me that a simple way to achieve this would be to have one example for each
function, with the name of the example file being the same as the name of
the function (à la Matlab!) Thus I have (re-)named the script as
"linecolor.py".
- At the moment, there seem to be too many places with examples:
screenshots, examples, gallery, scipy cookbook, figures for each function,
etc.
I think that the (refactored) gallery is the solution, and is where people
should be pointed -- the screenshots page and the examples page do not seem
to me to be useful / necessary.
- Also during the BoF / sprint, style sheets were discussed several times.
Tony seems to have already solved this problem in his mpltools package -- I
would suggest that this could be brought straight into Matplotlib?
Thanks to everybody for a great package (and for reading all this, if you
get this far). Please let me know if this is (not) the right place to
discuss such things.
Best wishes,
David.
-- 
**************************************************************************
Dr. David P. Sanders
Profesor Titular A / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)
dps...@gm...
http://sistemas.fciencias.unam.mx/~dsanders
Cubículo / office: #414
Tel.: +52 55 5622 4965

Ah ok that makes more sense, thanks!
So the change was made in c887139224<https://github.com/matplotlib/matplotlib/commit/c887139224ac30ceb2c77d249acf80da8ac9713e> "Backend factorisation for tooltip sharing".
Is there a reason backends can't provide access to the buttons from the toolbar object somehow though? The use-case is that GUIs using the Figure window can modify the buttons actions, e.g. to have the "save" button save various versions of a plot.
I don't think the means needs to be back-end agnostic, if you're mucking about with GUIs you've already accepted you are tied to a particular one.
Steve
________________________________
This email and any attached files are confidential and copyright protected. If you are not the addressee, any dissemination of this communication is strictly prohibited. Unless otherwise expressly agreed in writing, nothing stated in this communication shall be legally binding.
The ultimate parent company of the Atkins Group is WS Atkins plc. Registered in England No. 1885586. Registered Office Woodcote Grove, Ashley Road, Epsom, Surrey KT18 5BW. A list of wholly owned Atkins Group companies registered in the United Kingdom and locations around the world can be found at http://www.atkinsglobal.com/site-services/group-company-registration-details
Consider the environment. Please don't print this e-mail unless you really need to.

On 4 July 2013 13:27, Brasier, Steve <Ste...@at...> wrote:
> When I look in the svn browser here<http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/backends/backend_tkagg.py?annotate=8989>(which I assume is the current code?)
>
With no updates for the last couple of years? Try here:
https://github.com/matplotlib/matplotlib ;-)
Thomas