Reorganizing axes plot methods

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

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

···

On 2013/07/08 7:19 PM, Tony Yu wrote:

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@lists.sourceforge.net
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

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?

···

On 9 July 2013 08:24, Eric Firing <efiring@...229...> wrote:

On 2013/07/08 7:19 PM, Tony Yu wrote:

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
Matplotlib-devel@lists.sourceforge.net
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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 <nelle.varoquaux@…55…149…> wrote:

On 9 July 2013 08:24, Eric Firing <efiring@…229…> 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

Matplotlib-devel@lists.sourceforge.net

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

Matplotlib-devel@lists.sourceforge.net

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

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Thomas A Caswell
PhD Candidate University of Chicago
Nagel and Gardel labs
tcaswell@…1038…

jfi.uchicago.edu/~tcaswell
o: 773.702.7204

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

···

On Tue, Jul 9, 2013 at 1:24 AM, Eric Firing <efiring@...229...> wrote:

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

>> 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 :slight_smile: 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:43 AM, Nelle Varoquaux <nelle.varoquaux@...149...>wrote:

On 9 July 2013 08:24, Eric Firing <efiring@...229...> wrote:
> On 2013/07/08 7:19 PM, Tony Yu wrote: