This is very handy. +1.

The basic idea seems good. Ideally, I would think that each backend should provide a canvas in way that does not require the huge if...elif structure, but this would require a larger change, so perhaps it should be left until later. figure.py should not need to know about all possible backends; it should be able to do something like "import matplotlib.backends; matplotlib.backends.get_current_canvas()".

In any case, all backends supported by rcsetup.validate_backends (and listed in rcsetup.all_backends) should be included; some are missing at present.

Ah. I've only just read@efiring 's comment. It seems we agree on this issue. I definitely think this should be done properly at this stage, and would think it was cleaner to do this via the "backend_bases" module. Other than that, I think this is a great idea and will make working in a full OO way much easier.

@pelson: Thanks for finding the way to avoid the largeelif statement. I hadn't seen this earlier, so thought it was the best we could do for now. That's definitely preferable.

Yes@pelson! Good spot. I didn't think it was possible. I will obviously update to reflect this. Awesome! :D

Also, thanks@efiring,@pelson and@mdboom for looking through the code. You are all heroes.

I've rebased this against master to get theawesome changes from#1175. This will save me from conflicts with the changes I'm about to make.

I wonder whether as part of this PR, it would make sense to also update the documentation to add clearer information about the pure-OO API? At the moment, it's very hard to find any information about it. Maybe there should be a top-level section under 'User guide' that talks about the pure-OO API and the pros and cons compared to using pyplot or th hybrid pyplot-OO?

@astrofrog That's a great suggestion.

Would any of the wider community appreciate a couple of example scripts that use the object-oriented interface? I'd be happy to write some.

Ok, 3e4dea3 is a rather large commit.@pelson's suggestion of making each backend have aFigureCanvas as opposed to, say, aFigureCanvasAgg is a backwards incompatible change. Instead, I though it was better to just write an alias for each backend. That's the main crux of the new commit, just in case anybody didn't have the stamina to scroll through a colossal diff. In fact, I think one of the backends already had this alias, which is nice.

I'm still a newbie when it comes to the codebase, which is why I need you guys to tell me if I've put something in a sub-optimal place. You've been really helpful with all of my suggestions. So thank you.

Please test it out. Specifically, I don't want this to break anything inpylab. So if any of you arepylab users, your feedback is very welcome.

This pull requestfails (merged 3e4dea3a intocadd152).

Looks good. I would be happy to merge this once there was a docstring on_setup_canvas.

I know I'm always picky with newlines [and I hate myself for it ;-) ] but normally one would put a double new line between top level objects in a module (classes, functions, groups of constants etc.) and a single new line for the rest (in particular methods). I don't this doing this should block this PR though - I think this is a really helpful change.

@astrofrog 's suggestion of adding a section on pure OO & its benefits is a good idea, but lets keep this implementation and PR separate - there is no need to hold up one with the other.

@pelson - agree, the docs can be worked on in a different PR.

Should there be a way to optionally make it behave like before, i.e. to disable setting the canvas? e.g. something likeset_canvas or something like that? (that would default toTrue)

EDIT: alternatively, acanvas argument that defaults toauto but can be set toNone or a canvas instance?

This pull requestfails (mergedf83fbc9 intocadd152).

This pull requestfails (merged88e299b intocadd152).

Should there be a way to optionally make it behave like before, i.e. to disable setting the canvas?

I'm not that worried by it. The easy answer is for users to simply dofigure.canvas = None if they don't want the canvas which has been given to them. Maybe other have concerns about this?

Unless anybody has any concerns, I will merge this in 18 hours. Good stuff@dmcdougall.

@pelson - ok, I don't have a strong opinion about that, so we can just address it if people ask for it. I might open a PR if I run into issues with this some day.

Looking forward to using this! :-)

@astrofrog Thanks for the interest :) Glad I could help make someone's life easier.

Ah. I'm sorry@dmcdougall - I was a bit eager. Would you mind adding an entry in the what's new section?

@pelson And the changelog, too?

@pelson And the changelog, too?

My feeling is not. Your notbreaking anything, simply making one use case easier. We only need one entry: whichever you choose will be fine in this case.

I also added a nice example exposing the new change, just because there's no example anywhere else.

This pull requestfails (merged8738c1c intocadd152).

Thanks to@dmcdougall for doing the work & to@astrofrog for suggesting it. This is a real nice addition.