Awesome!

At a quick glance this looks like what I had in mind. I will look at it in detail tomorrow and probably produce PRs against your branch to deal with the rest of the backends.

I still have one question.

If the user doesn't want to use pyplot, how are these classes going to be used in scripting or interactive mode?
Or is it mandatory to use pyplot for scripting or interactive mode?

@efiring Yes, I know.
But because the idea was to separate the two, leaving the num argument there made no sense.
For backward compatibility it makes sense.
So I don't know what has priority, design goal or compatibility.

@fariza, in this case I would vote for compatibility, and include a very brief comment in backend_bases.py giving the rationale. The cost of having this optional argument (and corresponding attribute) that is not always used is very low. It some ways it makes the design cleaner by reducing LOC in the end result.

Even for the no-pyplot gui application, might it not be useful sometimes for the canvas to have a label or ID attribute, settable upon instantiation?

@efiring I agree, and that was one question that I posted in another thread.
Personally I feel the num to be useful, the only "problem" is that it belongs to pylab.

How about moving the Gcf outside pylab? maybe just rename it (something else than pylab_helpers.py)?
Why is not automatically assigned at figure instantiation?

@fariza I think Gcf is the heart of pylab/pyplot--keeping track of a set of figures, and maintaining the notion of a current figure. Perhaps the strange thing is that another critical internal organ, the tracking of a current Axes, is inside the Figure class itself, not factored out into a pyplot-specific location. Same for the current Image (actually, mappable object).
The overall strategy for any refactoring deserves more thought than I can give it at the moment, unfortunately.