matplotlib Hangout today at 14:00 UTC (10:00am ET)

Development matplotlib-devel
1

Just a reminder, we are having a general matplotlib development hangout today. Everyone that responded to the Doodle poll from a few weeks ago will get an invite, along with Matthew Terry and Matthew Brett if they can make it to discuss their work with testing and builds.

We have a few extra spots, so let me know if you'd like an invite (first come, first served).

I'll post a public URL to watch along once it begins as well.

Mike

···

--
                    _

\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
>>(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

2

Was anyone looking at the questions? I posted a bunch of questions but nobody seemed to notice them.

···

On Thu, Oct 24, 2013 at 3:41 PM, Michael Droettboom <mdroe@…31…> wrote:

Just a reminder, we are having a general matplotlib development hangout

today. Everyone that responded to the Doodle poll from a few weeks ago

will get an invite, along with Matthew Terry and Matthew Brett if they

can make it to discuss their work with testing and builds.

We have a few extra spots, so let me know if you’d like an invite (first

come, first served).

I’ll post a public URL to watch along once it begins as well.

Mike

–

                _

|/|o | . _ | | ._ ||| _ _ ._ _

| ||(| |(|(/| |/|()(/|_ ||)()()| | |

http://www.droettboom.com

October Webinars: Code for Performance

Free Intel webinars can help you accelerate application performance.

Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from

the latest Intel processors and coprocessors. See abstracts and register >

http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

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

3

Here are the notes with action items from the meeting:

Sorry about not seeing questions posted from non-participants. I'll try to work out that kink for next time.

Mike

···

On 10/24/2013 09:41 AM, Michael Droettboom wrote:

Just a reminder, we are having a general matplotlib development hangout
today. Everyone that responded to the Doodle poll from a few weeks ago
will get an invite, along with Matthew Terry and Matthew Brett if they
can make it to discuss their work with testing and builds.

We have a few extra spots, so let me know if you'd like an invite (first
come, first served).

I'll post a public URL to watch along once it begins as well.

Mike

--
                    _

\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
>>(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

4

Hi,
For the CI stuff, I think it would be worth discussing this with the
Enthought guys, specifically Didrik Pinte and David Cournapeau.

From what I understood, they are developping some stuff to

automatically build canopy from projects hosted on github. Hence, they
have to run all the tests, on different plateforms, and they are OK
with chatting with some of us.
Cheers,
N

···

On 24 October 2013 17:29, Michael Droettboom <mdroe@...31...> wrote:

Here are the notes with action items from the meeting:

https://docs.google.com/document/d/1nVM9qDooU5nX6WSKWPTYd2kN6wBxqOWZZTNOM1k0FdA/edit?usp=sharing

Sorry about not seeing questions posted from non-participants. I'll try
to work out that kink for next time.

Mike

On 10/24/2013 09:41 AM, Michael Droettboom wrote:

Just a reminder, we are having a general matplotlib development hangout
today. Everyone that responded to the Doodle poll from a few weeks ago
will get an invite, along with Matthew Terry and Matthew Brett if they
can make it to discuss their work with testing and builds.

We have a few extra spots, so let me know if you'd like an invite (first
come, first served).

I'll post a public URL to watch along once it begins as well.

Mike

--
                    _
>\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
> >>(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

5

Here are the questions I asked during the hangouts session (paraphrased):

···

Regarding continuous integration:

Has looked into OBS? (open build server, https://build.opensuse.org/) It can be installed on a local machine or server, supports automatically creating and deleting fresh images with each build, and supposedly works with osX as well as Linux although I haven’t tested it (it does need a Mac OsX VM).

Regarding bug handling:

It might be possible to do something with this with Google Code-in (https://developers.google.com/open-source/gci/), although I am not 100% sure this would be acceptable there.

Another possibility would be to allow volunteer triagers who may not be developers but can at least handle basic stuff like finding duplicates and following up with the reporters of old bugs.

Regarding embedding:

Perhaps there could be a generic “figure” widget for each backend. The widget would automatically handle all the backend-specific stuff necessary to create a figure object and display it in the widget (including resizing and such). It would provide access to the low-level backend-specific parts to make it possible to subclass it or change the details of how it works. The figure windows would have this widget as their central widget, and would probably access it using these low-level components.

However, for basic usage each widget would also have a “figure” attribute, which would contain a single generic figure object. Basic users who just want to embed a regular plot could access that figure object and use it in the normal way.

These could probably all be accessed from a single module, although they probably would all live in their own backend-specific modules.

It wouldn’t allow people to use pyplot, but if this was the documented way to do embedding and the documentation made it clear you needed to use the OO interface when embedding I think it would greatly reduce the amount of trouble people have.

6

thanks for posting that. I see:

pylab - should it stay or should it go?

Comment from the peanut gallery:

Go.

But beyond that, matplotlib.pyplot is a big mess of both the
matlab-style state-machine current figure, current axis stuff, and
what you need to do (at least reasonably on the command line) OO
interface.

This makes it really hard to teach to newbies -- I just did this last
night, and made a point to use tutorials that emphasize the OO
interface (Thanks Ben Root, Katy Huff, and Antony Scopatz, and I'm
sure others that helped put the materials together that I stole
from...). However, there were still a number of examples in there that
just called "plot()" or whatever, and even if there were not, the
namespace is really cluttered with stuff!

Anyone like the idea of an matplotlib.ooplot namespace that would have
just what you need to use the oo style?

-Chris

···

On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom <mdroe@...31...> wrote:

Here are the notes with action items from the meeting:

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...236...

7

Hello,

I agree that the matlab like API should be at least discouraged, however
I think there are some shortcomings both in the documentation and
examples and in the object oriented API and functions exposed through
the pyplot namespace that make switching more cumbersome that it has to bee.

One thing I dislike is, for example, the add_subplot() method:

f = plt.figure()
a = f.add_subplot(111)
a.plot(x, y)

it feels completely out of place (why I need to add a subplot if the
only thing I want to do is to create a figure with a single plot in it?)
and kind of magic (what is the number 111?).

The API is also very old fashion python (getter and setter methods for
example) and many methods try to emulate too much of the bad API design
of matlab (doing completely different things depending on the kind and
number of parameters).

I believe it would be possible to come up with a more modern and lean
API that would be easier and nicer to use. If we have to deprecate the
matlab style API, maybe it would be worth to replace it with something
substantially better.

PS: Chris, would you mind sharing the material you put together and
links to material from which you stole from? Thanks!

Cheers,
Daniele

···

On 24/10/2013 20:39, Chris Barker wrote:

On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom <mdroe@...31...> wrote:

Here are the notes with action items from the meeting:

thanks for posting that. I see:

pylab - should it stay or should it go?

Comment from the peanut gallery:

Go.

But beyond that, matplotlib.pyplot is a big mess of both the
matlab-style state-machine current figure, current axis stuff, and
what you need to do (at least reasonably on the command line) OO
interface.

This makes it really hard to teach to newbies -- I just did this last
night, and made a point to use tutorials that emphasize the OO
interface (Thanks Ben Root, Katy Huff, and Antony Scopatz, and I'm
sure others that helped put the materials together that I stole
from...). However, there were still a number of examples in there that
just called "plot()" or whatever, and even if there were not, the
namespace is really cluttered with stuff!

Anyone like the idea of an matplotlib.ooplot namespace that would have
just what you need to use the oo style?

8

One quick reply:

Daniele Nicolodi, on 2013-10-24 21:03, wrote:

One thing I dislike is, for example, the add_subplot() method:

f = plt.figure()
a = f.add_subplot(111)
a.plot(x, y)

it feels completely out of place (why I need to add a subplot if the
only thing I want to do is to create a figure with a single plot in it?)
and kind of magic (what is the number 111?).

  f, a = plt.subplots()
  a.plot(x, y)

that's the way to go there. And if you need to make a regular
grid of subplots, you can pass it the number of rows and number
of columns, and get a 2D array of subplots out for the second
argument.

  f, axes = plt.subplots(2,3)
  axes[0,2].plot(range(10))
  axes[1,1].plot(-np.arange(10))
  f.canvas.draw()

best,

···

--
                   _
                  / \
                A* \^ -
             ,./ _.`\\ / \
            / ,--.S \/ \
           / `"~,_ \ \
     __o ?
   _ \<,_ /:\
--(_)/-(_)----.../ | \
--------------.......J
Paul Ivanov
http://pirsquared.org

9

Michael Droettboom, on 2013-10-24 09:41, wrote:

I'll post a public URL to watch along once it begins as well.

Here's the youtube video link (which I got from Mike's G+):

best,

···

--
                   _
                  / \
                A* \^ -
             ,./ _.`\\ / \
            / ,--.S \/ \
           / `"~,_ \ \
     __o ?
   _ \<,_ /:\
--(_)/-(_)----.../ | \
--------------.......J
Paul Ivanov
http://pirsquared.org

10

PS: Chris, would you mind sharing the material you put together and
links to material from which you stole from? Thanks!

I honestly don't think my stuff is any better than the originals: I like these:

Ben Root's Scipy Tutorial -- really nice, Ben!
  GitHub - matplotlib/AnatomyOfMatplotlib: Anatomy of Matplotlib -- tutorial developed for the SciPy conference

From the software carpentry site:

  https://github.com/swcarpentry/bc/tree/gh-pages/lessons/thw-matplotlib
(apparently originally from Katy and Antony)

-Chris

···

On Thu, Oct 24, 2013 at 12:03 PM, Daniele Nicolodi <daniele@...1172...> wrote:

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...236...

11

That's better, however to create _sub_ plots to have a single plot into
a figure still feels weird, also I would expect it to be a method of the
Figure class and not a top level function. Furthermore, most
documentation refers to add_subplot() and not subplots() which has a
more understandable function signature.

In principle I think the current API violates the "There should be one--
and preferably only one --obvious way to do it" rule here, and elsewhere :slight_smile:

I feel the way forward should be to create a cleaner API and map the
current one through a compatibility layer to that.

Cheers,
Daniele

···

On 24/10/2013 21:26, Paul Ivanov wrote:

One quick reply:

Daniele Nicolodi, on 2013-10-24 21:03, wrote:

One thing I dislike is, for example, the add_subplot() method:

f = plt.figure()
a = f.add_subplot(111)
a.plot(x, y)

it feels completely out of place (why I need to add a subplot if the
only thing I want to do is to create a figure with a single plot in it?)
and kind of magic (what is the number 111?).

  f, a = plt.subplots()
  a.plot(x, y)

12

Daniele,

···

On Fri, Oct 25, 2013 at 8:45 AM, Daniele Nicolodi <daniele@…1172…> wrote:

On 24/10/2013 21:26, Paul Ivanov wrote:

One quick reply:

Daniele Nicolodi, on 2013-10-24 21:03, wrote:

One thing I dislike is, for example, the add_subplot() method:

f = plt.figure()

a = f.add_subplot(111)

a.plot(x, y)

it feels completely out of place (why I need to add a subplot if the

only thing I want to do is to create a figure with a single plot in it?)

and kind of magic (what is the number 111?).

f, a = plt.subplots()

a.plot(x, y)

That’s better, however to create sub plots to have a single plot into

a figure still feels weird,

It doesn’t feel weird. It feels generalized. It is the same way to add any number of plots, regardless if it is just one, or twenty. If you don’t want to do it that way, you can just simply do:

fig = plt.figure()

ax = fig.gca() # “get current axes” automatically creates an axes if one doesn’t exist already

You also have http://matplotlib.org/api/figure_api.html#matplotlib.figure.Figure.add_axes

also I would expect it to be a method of the

Figure class and not a top level function.

It does:
http://matplotlib.org/api/figure_api.html#matplotlib.figure.Figure.add_subplot

This is the function that does axes creation for a figure, whether it is one, or many.

Furthermore, most

documentation refers to add_subplot() and not subplots() which has a

more understandable function signature.

subplots() is a recent addition. We are in the process of updating our documentation. But add_subplot() is not going away because it works just fine, and it is very familiar to users of Matlab and Octave.

In principle I think the current API violates the "There should be one–

and preferably only one --obvious way to do it" rule here, and elsewhere :slight_smile:

I feel the way forward should be to create a cleaner API and map the

current one through a compatibility layer to that.

This has already been done. We have the GridSpec API that everything else maps to, for compatibility. But most people still like add_subplot() and subplots() for some odd reason… I think the primary issue is one of documentation, and we are currently in the process of upgrading that. We always welcome contributions to that effort!

Cheers!
Ben Root

13

Hello Benjamin,

thanks for your comments. I'm aware of the solutions you propose, but I
maintain that the status quo is confusing for new users.

The fact that there are multiple ways of doing the same thing, through
apparently unrelated interfaces makes the API more difficult to learn
and less discoverable that it needs to be. This is probably a
conseqence of the organic growth of the library with time.

I agree that the primary issue is the documentation, but at the root of
that I also feel there is the lack of well established best practices
for the use of Matplotlib. For example you write that people still like
add_subplot() and subplots() for odd reasons, which are the methods
others in the lists pointed to. What would be the proper API to use in
your opinion? I believe convergence on best practices is paramount to
the update of the documentation.

I also don't really buy the argument that it is desirable to keep and
promote APIs that try to emulate the Matlab interface. Matplotlib is
different enough to make a 1:1 translation difficult and the Matlab
design is anyhow broken, IMHO.

Best,
Daniele

PS: with a new job also came the possibility to finally drop Matlab and
embrace Python as the main data analysis tool. This means that I can
dedicate some (at the moment very few) spare cycles to contribute to
Matplotlib. I would be happy to do so!

···

On 25/10/2013 15:34, Benjamin Root wrote:

This has already been done. We have the GridSpec API that everything
else maps to, for compatibility. But most people still like
add_subplot() and subplots() for some odd reason... I think the primary
issue is one of documentation, and we are currently in the process of
upgrading that. We always welcome contributions to that effort!

14

There needs to be layers to the interface. At the bottom there is super general stuff that will cover (we hope) 100% of use cases. However, the cost is a very verbose interface with lots of knobs. To cope with this there are higher level function which can deal with 90% of the use cases and do so by hiding some of the knobs (compare making a 3x3 grid subplots(3, 3) with using GridSpec to figuring out where the axes edges should go and using add_subplot([t, l, w, h]) ). I want to make an analogy to projecting from a higher dimensional parameter space to a lower one.

The ‘proper’ api to use is the simplest one that achieves your goal. If you just need a grid of evenly spaced equal size axes use subplots, if you need a grid but with some axes that span columns/rows use GridSpec, if you need 5 axes that partially overlap in the shape of your school logo, use add_subplot.

The point of the high-level APIs is to be easy to use. If that means matching the MATLAB api to make it easier for people to switch, then fine. I am sympathetic to the notion that the state-machine interface is confusing (because it maintains hidden state), but it is in fact very convenient.

···

On Fri, Oct 25, 2013 at 10:26 AM, Daniele Nicolodi <daniele@…1172…> wrote:

On 25/10/2013 15:34, Benjamin Root wrote:

This has already been done. We have the GridSpec API that everything

else maps to, for compatibility. But most people still like

add_subplot() and subplots() for some odd reason… I think the primary

issue is one of documentation, and we are currently in the process of

upgrading that. We always welcome contributions to that effort!

Hello Benjamin,

thanks for your comments. I’m aware of the solutions you propose, but I

maintain that the status quo is confusing for new users.

The fact that there are multiple ways of doing the same thing, through

apparently unrelated interfaces makes the API more difficult to learn

and less discoverable that it needs to be. This is probably a

conseqence of the organic growth of the library with time.

I agree that the primary issue is the documentation, but at the root of

that I also feel there is the lack of well established best practices

for the use of Matplotlib. For example you write that people still like

add_subplot() and subplots() for odd reasons, which are the methods

others in the lists pointed to. What would be the proper API to use in

your opinion? I believe convergence on best practices is paramount to

the update of the documentation.

I also don’t really buy the argument that it is desirable to keep and

promote APIs that try to emulate the Matlab interface. Matplotlib is

different enough to make a 1:1 translation difficult and the Matlab

design is anyhow broken, IMHO.

Best,

Daniele

PS: with a new job also came the possibility to finally drop Matlab and

embrace Python as the main data analysis tool. This means that I can

dedicate some (at the moment very few) spare cycles to contribute to

Matplotlib. I would be happy to do so!

October Webinars: Code for Performance

Free Intel webinars can help you accelerate application performance.

Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from

the latest Intel processors and coprocessors. See abstracts and register >

http://pubads.g.doubleclick.net/gampad/clk?id=60135991&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

15

I agree, but that leads to another question: go where?

Some of the stuff there is clearly redundant and should be removed entirely.

Others I think are functionality that should be merged into numpy, although whether they would agree I don’t know.

Others are useful but I don’t know exactly where they could end up.

I think we need to go through on a case-by-case basis and figure out what to do with each class and function.

I think it would probably be good to do something similar with cbook. Both are dumping grounds for largely unrelated functions. At the very least they should be organized into modules by their purpose, but I do think some should be dropped or upstreamed.

···

On Oct 24, 2013 8:40 PM, “Chris Barker” <chris.barker@…236…> wrote:

On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom <mdroe@…31…> wrote:

Here are the notes with action items from the meeting:

thanks for posting that. I see:

pylab - should it stay or should it go?

Comment from the peanut gallery:

Go.

16

It doesn't feel weird. It feels generalized.

or both :wink:

It is the same way to add any number of plots, regardless if it is just

one, or twenty. If you don't want to do it that way, you can just simply do:

fig = plt.figure()
ax = fig.gca() # "get current axes" automatically creates an axes if one

rally ugly -- the whole point here is to get away from the concept of a
"current" anything -- I'm actually surprised that that's a figure method at
all...

It does:

http://matplotlib.org/api/figure_api.html#matplotlib.figure.Figure.add_subplot

This is *the* function that does axes creation for a figure, whether it is
one, or many.

subplots() is a recent addition.

And a nice one -- I've been wanting that for years! (and I
first discovered it in your tutorial, Ben!) The trick has always been that
plot() actually creates (If not re-using) three objects you might want to
work with: figure, axes, and line objects, so an oo interface that lets you
do that with one call is tricky -- I think this is a nice compromise.

We are in the process of updating our documentation. But add_subplot() is

not going away because it works just fine, and it is very familiar to users
of Matlab and Octave.

I've lost track a bit if there is support for a new OO-only API
(namespace), in which case, maybe some of this could be cleaned up as well.

I'd kind of like to see a fig.subplots() that has the same API as
plt.subplots(), for symmetry's sake, and because add_subplot() has a kind
of crufty API. Except it wouldn't return the figure instance (though it
could).

-Chris

···

On Fri, Oct 25, 2013 at 6:34 AM, Benjamin Root <ben.root@...553...> wrote:

In principle I think the current API violates the "There should be one--
and preferably only one --obvious way to do it" rule here, and elsewhere
:slight_smile:

I feel the way forward should be to create a cleaner API and map the

current one through a compatibility layer to that.

This has already been done. We have the GridSpec API that everything else
maps to, for compatibility. But most people still like add_subplot() and
subplots() for some odd reason... I think the primary issue is one of
documentation, and we are currently in the process of upgrading that. We
always welcome contributions to that effort!

Cheers!
Ben Root

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...236...

17

I think one thing that contributes a lot to the API issues is the
inconsistency between pyplot API and the OO API. There isn't any reason
the APIs need to be so different.

To continue with this example, pyplot.subplot and Figure.add_subplot do
basically the same thing, but they have different names. In practice
pyplot.subplot essentially acts as a wrapper for gcf().add_subplot, but it
isn't exactly the same internally, it has some checks that are not present
in Figure.add_subplot but really should be.

On the other hand, pyplot.subplots doesn't exist at all in Figure, all the
functionality is implemented in pyplot.

So the idea would be to have essentially all of the pyplot functions just
be wrappers for methods from other classes, using the same name and same
call signature (minus "self"). All of the actual functionality would be
implemented in the methods, the pyplot functions should not have any logic
or tests.

So pyplot.subplot would be just be a wrapper for gcf().subplot,
pyplot.subplots would just be a wrapper for gcf().subplots, while
pyplot.plot would just be a wrapper for gcf().gca().plot.

This will make it easy to transition between the two, learning to use the
OO interface would just involve learning what object the pyplot function is
targeting (this should be in the pyplot function docstring).

···

On Fri, Oct 25, 2013 at 7:21 PM, Thomas A Caswell <tcaswell@...1038...>wrote:

There needs to be layers to the interface. At the bottom there is super
general stuff that will cover (we hope) 100% of use cases. However, the
cost is a very verbose interface with lots of knobs. To cope with this
there are higher level function which can deal with 90% of the use cases
and do so by hiding some of the knobs (compare making a 3x3 grid
`subplots(3, 3)` with using `GridSpec` to figuring out where the axes
edges should go and using `add_subplot([t, l, w, h])` ). I want to make an
analogy to projecting from a higher dimensional parameter space to a lower
one.

The 'proper' api to use is the simplest one that achieves your goal. If
you just need a grid of evenly spaced equal size axes use `subplots`, if
you need a grid but with some axes that span columns/rows use `GridSpec`,
if you need 5 axes that partially overlap in the shape of your school logo,
use `add_subplot`.

The point of the high-level APIs is to be easy to use. If that means
matching the MATLAB api to make it easier for people to switch, then fine.
I am sympathetic to the notion that the state-machine interface is
confusing (because it maintains hidden state), but it is in fact very
convenient.

On Fri, Oct 25, 2013 at 10:26 AM, Daniele Nicolodi <daniele@...1172...>wrote:

On 25/10/2013 15:34, Benjamin Root wrote:

> This has already been done. We have the GridSpec API that everything
> else maps to, for compatibility. But most people still like
> add_subplot() and subplots() for some odd reason... I think the primary
> issue is one of documentation, and we are currently in the process of
> upgrading that. We always welcome contributions to that effort!

Hello Benjamin,

thanks for your comments. I'm aware of the solutions you propose, but I
maintain that the status quo is confusing for new users.

The fact that there are multiple ways of doing the same thing, through
apparently unrelated interfaces makes the API more difficult to learn
and less discoverable that it needs to be. This is probably a
conseqence of the organic growth of the library with time.

I agree that the primary issue is the documentation, but at the root of
that I also feel there is the lack of well established best practices
for the use of Matplotlib. For example you write that people still like
add_subplot() and subplots() for odd reasons, which are the methods
others in the lists pointed to. What would be the proper API to use in
your opinion? I believe convergence on best practices is paramount to
the update of the documentation.

I also don't really buy the argument that it is desirable to keep and
promote APIs that try to emulate the Matlab interface. Matplotlib is
different enough to make a 1:1 translation difficult and the Matlab
design is anyhow broken, IMHO.

Best,
Daniele

PS: with a new job also came the possibility to finally drop Matlab and
embrace Python as the main data analysis tool. This means that I can
dedicate some (at the moment very few) spare cycles to contribute to
Matplotlib. I would be happy to do so!

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from
the latest Intel processors and coprocessors. See abstracts and register >

http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

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

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

18

I think another problem is having pyplot and axes as dumping grounds for
all plot types. This probably made sense back when there were only a few
types of plots, but now there is a massive number of them. They all end up
in one large class with one large documentation page, making it very hard
to find exactly what you are looking for.

In order to make the plots really useful, I definitely think a
reorganization is in order. I think matplotlib needs an general module,
perhaps "plots", that contains sub-modules for different types of plots
(like bar plots), and those sub-modules contain functions, all of which
have an axes object as their first argument. These could still be attached
to axes as methods at least as a transition, but it would leave the axes
class with methods that really have to do with axes, and not plotting per
se. This would also make it possible to put code shared between plot types
with those plot types in their module.

···

On Thu, Oct 24, 2013 at 8:39 PM, Chris Barker <chris.barker@...236...> wrote:

On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom <mdroe@...31...> > wrote:
> Here are the notes with action items from the meeting:

thanks for posting that. I see:

pylab - should it stay or should it go?

Comment from the peanut gallery:

Go.

But beyond that, matplotlib.pyplot is a big mess of both the
matlab-style state-machine current figure, current axis stuff, and
what you need to do (at least reasonably on the command line) OO
interface.

This makes it really hard to teach to newbies -- I just did this last
night, and made a point to use tutorials that emphasize the OO
interface (Thanks Ben Root, Katy Huff, and Antony Scopatz, and I'm
sure others that helped put the materials together that I stole
from...). However, there were still a number of examples in there that
just called "plot()" or whatever, and even if there were not, the
namespace is really cluttered with stuff!

Anyone like the idea of an matplotlib.ooplot namespace that would have
just what you need to use the oo style?

-Chris

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...236...

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

19

Nelle Varaquoax has already started this work on master. The
separation of core axes functionality from plotting functionality
has already been done, and the next steps involve organizing the
plotting functionality further. This is a gargantuan task, and I’m
sure Nelle would appreciate some assistance if you wanted to
coordinate with her.
Mike

···

On 10/25/2013 06:42 PM, Todd wrote:

        I think another problem is having

pyplot and axes as dumping grounds for all plot types. This
probably made sense back when there were only a few types of
plots, but now there is a massive number of them. They all
end up in one large class with one large documentation page,
making it very hard to find exactly what you are looking
for.

        In order to make the plots really useful, I definitely think

a reorganization is in order. I think matplotlib needs an
general module, perhaps “plots”, that contains sub-modules
for different types of plots (like bar plots), and those
sub-modules contain functions, all of which have an axes
object as their first argument. These could still be
attached to axes as methods at least as a transition, but it
would leave the axes class with methods that really have to
do with axes, and not plotting per se. This would also make
it possible to put code shared between plot types with those
plot types in their module.

        On Thu, Oct 24, 2013 at 8:39 PM, Chris Barker <chris.barker@...236...>
        wrote:

            On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom

<mdroe@…31… >
wrote:

            > Here are the notes with action items from the

meeting:

thanks for posting that. I see:

          pylab - should it stay or should it go?



          Comment from the peanut gallery:



          Go.



          But beyond that, matplotlib.pyplot is a big mess of both

the

          matlab-style state-machine current figure, current axis

stuff, and

          what you need to do (at least reasonably on the command

line) OO

          interface.



          This makes it really hard to teach to newbies -- I just

did this last

          night, and made a point to use tutorials that emphasize

the OO

          interface (Thanks Ben Root, Katy Huff, and Antony Scopatz,

and I’m

          sure others that helped put the materials together that I

stole

          from...). However, there were still a number of examples

in there that

          just called "plot()" or whatever, and even if there were

not, the

          namespace is really cluttered with stuff!



          Anyone like the idea of an matplotlib.ooplot namespace

that would have

          just what you need to use the oo style?



              -Chris



              --



              Christopher Barker, Ph.D.

              Oceanographer



              Emergency Response Division

              NOAA/NOS/OR&R            (206) 526-6959   voice

              7600 Sand Point Way NE   (206) 526-6329   fax

              Seattle, WA  98115       (206) 526-6317   main reception



              Chris.Barker@...236...

              October Webinars: Code for Performance

              Free Intel webinars can help you accelerate

application performance.

              Explore tips for MPI, OpenMP, advanced profiling, and

more. Get the most from

              the latest Intel processors and coprocessors. See

abstracts and register >

              [http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk](http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk)

              _______________________________________________

              Matplotlib-devel mailing list

              Matplotlib-devel@lists.sourceforge.net

              [https://lists.sourceforge.net/lists/listinfo/matplotlib-devel](https://lists.sourceforge.net/lists/listinfo/matplotlib-devel)

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register >

_______________________________________________
Matplotlib-devel mailing list

                   -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrkMatplotlib-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-develhttp://www.droettboom.com

20

I think one thing that contributes a lot to the API issues is the
inconsistency between pyplot API and the OO API. There isn't any reason
the APIs need to be so different.

indeed.

I hadn't even realized how different they were.

So the idea would be to have essentially all of the pyplot functions just
be wrappers for methods from other classes, using the same name and same
call signature (minus "self"). All of the actual functionality would be
implemented in the methods, the pyplot functions should not have any logic
or tests.

+ inf

However, doing this with full backward compatibility could be a real
challenge...

This will make it easy to transition between the two, learning to use the

OO interface would just involve learning what object the pyplot function is
targeting (this should be in the pyplot function docstring).

That would help, though a namespace without any non-OO stuff would be still
be good, and, of course, docs and tutorials.

-Chris

···

On Fri, Oct 25, 2013 at 3:32 PM, Todd <toddrjen@...149...> wrote:

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...236...