Feature request - make it simpler to use full OO interface #1094

astrofrog · 2012-08-16T13:31:54Z

I would like to start using the matplotlib OO interface more, as I would prefer to use this when interactive plotting is not needed. It it slightly faster, and behaves more intuitively in terms of reference counting (pyplot keeps a reference to each figure, meaning that if figures are not closed by pyplot, memory goes out of control).

The reason I don't use it is because it's not easy to remember all the set-up of the canvas and figure:

from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
from matplotlib.figure import Figure

fig = Figure()
canvas = FigureCanvas(fig)
ax = fig.add_subplot(1, 1, 1)
ax.scatter(np.random.random(10), np.random.random(10))
fig.savefig('test.png')

So I was wondering whether it would be possible to make Figure more intelligent in terms of canvas? The 'ideal' API in my mind would be:

from matplotlib.figure import Figure

fig = Figure()
ax = fig.add_subplot(1, 1, 1)
ax.scatter(np.random.random(10), np.random.random(10))
fig.savefig('test.png')

i.e. I want the figure to just use the default backend (since this is set at the root level of matplotlib, not pyplot). So I would expect the following to work:

import matplotlib
matplotlib.use('Agg')
from matplotlib.figure import Figure

fig = Figure()
ax = fig.add_subplot(1, 1, 1)
ax.scatter(np.random.random(10), np.random.random(10))
fig.savefig('test.png')

and to use the non-interactive Agg backend.

Is this something that has been considered before?

The text was updated successfully, but these errors were encountered:

WeatherGod · 2012-08-16T13:47:37Z

It would probably be cleaner this way. Currently, pyplot.figure() invokes the new_figure_manager function that is (somehow) established by the init.py module in matplotlib.backends. It would probably be wise to look at this area of code again to see how we can clean this up anyway.

dmcdougall · 2012-08-21T10:44:54Z

Setting pyplot aside for the moment, is there anything to stop the canvas being set up in the Figure constructor? At the moment, Figure.__init__ has the line:

self.canvas = None

Which is evidenced by:

In [1]: from matplotlib.figure import Figure

In [2]: fig = Figure()

In [3]: print fig.canvas
None

One way to work around this is to retrieve the default backend in the __init__ method in the constructor, which should exist either from a matplotlib.use('mybackend') or from rcParams. This can be done using a matplotlib.get_backend() call.

Is there something deeper I am missing?

astrofrog · 2012-08-21T10:51:27Z

@dmcdougall - this is exactly what I mean, and I believe it would make it a lot easier for people to use this API.

dmcdougall · 2012-08-21T10:59:25Z

So I tried this out, and it seems to work ok. I can't say anything for pyplot. Though, if you're using pyplot, you're probably not interested in the OO interface. I can submit a PR if any of the more experienced mpl developers would like to give some input...

dmcdougall · 2012-09-08T22:12:16Z

@efiring Should this be re-opened because of #1221?

efiring · 2012-09-08T22:44:32Z

This might have worked if carefully restricted to non-interactive backends. I think it requres some careful thought and experimentation, though. It may be that the way to handle it is via a kwarg to the Figure constructor, explicitly designating a non-interactive backend; or maybe in the code as you had it, attaching the canvas to the figure upon Figure initialization would be done only if the default backend is non-interactive. All of the messy figure management machinery is needed only for screen display, not for savefig, I believe.
A problem with this approach is that although it simplifies some things, it adds overall complexity in that something that works for a non-interactive backend fails if the default backend is interactive. So, it might cause more trouble (puzzled users, mailing list traffic) than it is worth.

berr · 2012-10-30T10:27:15Z

@efiring Do you think we can find a way to implement this issue without changing the interactive workflow? I have some spare time on the next few weeks and would like to work on that.

efiring · 2012-10-31T00:09:42Z

You are certainly welcome to try. I'm out on a ship until mid-Nov., and then busy into December, so I probably won't be much help. If you can come up with something that makes the whole Figure/Canvas dance simpler and easier to understand at the lowest code level as well as at the user level--and that doesn't break anything--that will be very good.

berr · 2012-10-31T01:21:56Z

I'll sure give it a try.
Is there a dev mailing list / irc channel that I can use to find someone if I need guidance? (couldn't find anything on the site)

mdboom · 2012-10-31T01:23:12Z

matplotlib-devel is a good place to reach other developers:

https://sourceforge.net/mailarchive/forum.php?forum_name=matplotlib-devel

dmcdougall · 2012-10-31T02:06:06Z

@berr I've been working on an alternative solution to this, and currently have an implementation illustrating some degree of success. That said, I would be interested to see if you come up with a similar approach. Do you have a branch I can take a cheeky fork of?

berr · 2012-10-31T02:48:18Z

@dmcdougall Not yet. I'm planning to start this on the next week. Since you've already started, I can use your work as a starting point or even just continue it. Do you have it on a branch that I could see?

dmcdougall · 2012-10-31T02:55:41Z

@berr Yes, but don't let it pollute your train of thought. I tried this once before and failed epicly. This new approach is a better version, and I haven't worked on it for a while so I'm not sure if it still works... The branch is here. I hope it's helpful.

dmcdougall · 2012-10-31T02:57:14Z

IIRC, I had problems with the Qt4 backend...

demitri · 2012-11-07T21:12:08Z

Just want to add my +1 to strongly support a fully OO plotting interface.

dmcdougall · 2012-11-07T21:16:11Z

@demitri Thanks. Good to know this would be used.

@berr Did you try out my branch?

dmcdougall · 2013-02-19T19:07:07Z

Turns out this is rather hard to implement without a significant backend redesign and/or refactor. See discussion in #1457.

dmcdougall mentioned this issue Aug 21, 2012

Reduce object-oriented boilerplate for users #1125

Merged

pelson closed this as completed Sep 4, 2012

efiring reopened this Sep 8, 2012

dmcdougall mentioned this issue Nov 8, 2012

Better object-oriented interface for users #1457

Closed

dmcdougall closed this as completed Feb 19, 2013

Uh oh!

Feature request - make it simpler to use full OO interface #1094

Feature request - make it simpler to use full OO interface #1094

Comments

astrofrog commented Aug 16, 2012

WeatherGod commented Aug 16, 2012

Uh oh!

dmcdougall commented Aug 21, 2012

Uh oh!

astrofrog commented Aug 21, 2012

Uh oh!

dmcdougall commented Aug 21, 2012

Uh oh!

dmcdougall commented Sep 8, 2012

Uh oh!

efiring commented Sep 8, 2012

Uh oh!

berr commented Oct 30, 2012

Uh oh!

efiring commented Oct 31, 2012

Uh oh!

berr commented Oct 31, 2012

Uh oh!

mdboom commented Oct 31, 2012

Uh oh!

dmcdougall commented Oct 31, 2012

Uh oh!

berr commented Oct 31, 2012

Uh oh!

dmcdougall commented Oct 31, 2012

Uh oh!

dmcdougall commented Oct 31, 2012

Uh oh!

demitri commented Nov 7, 2012

Uh oh!

dmcdougall commented Nov 7, 2012

Uh oh!

dmcdougall commented Feb 19, 2013

Uh oh!