matplotlib-devel Mailing List for matplotlib

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