F1 = OOlab.Figure() F2 = OOlab.Figure()
We have this:
fig1 = pylab.figure()
fig2 = pylab.figure()
ax1 = fig.add_subplot(111)
line, = ax1.plot([1,2,3])
line.set_color('green')
ax1.set_title('hi mom')
Yes, it would be nice to be able to do
ax1.title = 'hi mom'
but other than that pretty much everything you describe already
exists.
Instead of thinking about OOlab, which mostly already exists, I think
it's more useful to focus on a few shortcuts which will make OO use as
easy as pylab. It is already -- I pretty much use the OO interface
exclusively in all my work. All my scripts start with
from pylab import figure, close, show, nx
and that's all, and it works fine.
One helpful tip: the children point to their parents, so expanding on
Jeff's point about the line containing a pointer to the axes it lives
in, you can also reference the figure and canvas as upstream
containers
line.axes.figure.canvas.draw()
for example.
> Why couldn't plot(x,y) create and return a figure
> object? Or an axis object? -- I haven't thought it
> out too much yet.
Because it returns a line object. But I do think it is a design
limitation to plot make an axes method.
>> For interactive use, I really don't see any advantage to an OO
> interface.
> Well, for *just* interactive use, I agree, but I see
> some very large advantages to an OO style for
> embedding in programs and larger projects.
Sure, all programmers agree with that. For scripts and apps, the OO
interface is clearly superior. Teachers teaching students who are new
to programming, however, are adamant that the pylab/proceedural
interface is crucial to get them to adopt python over matlab, and I
trust them. And for interactive quick-and-dirty minimize-the-typing
work, the current figure, current axes approach is quite handy.
> As handy as it is to have a command line to play
> with, if I'm writing more than four or five lines
> (and I usually am!), I'm happier putting them in a
> file and running them as a script. Even in that case,
> I don't mind a little extra typing.
> What I'm envisioning for "OOlab" is a set of utility
> functions that do make some of the pylab stuff easy
> -- not well thought out yet, but something like:
It's all there with the exception of GUI window management, and you
might as well use pylab for that. That saves you a lot of
boilerplate.
> F = ooLab.figure(1) # I often need to plot more than
> one figure anyway, so I don't mind having to type
> that.
> ax = F.plot(x,y) # there could be this and subplot
Well, this breaks the whole concept of multiple axes, though one could
have a helper function that assumes subplot(111) ... But explicit is
better than implicit so may as well instantiate the Axes with
fig.add_subplot...
> ax.set_title = "A title for the plot" # or better
> yet: ax.title = "A title for the plot" # I'd like to
> see more properties in MPL too!
Agreed.
> ax.grid(True) . . .
Exists...
> Note that some of this comes from my love of
> namespaces -- I really don't like "import*" -- the
> way that can work is using more OO, so you don't need
> to type the module name everywhere.
With the exception of ipython -pylab, noone is forcing you to import
*. And on the subject, Fernando, perhaps we should support a pylab
mode in ipython which doesn't dump the pylab namespace (or maybe just
dumps the required figure, show, close, nx), but does the interactive
backend stuff.
> I don't see much advantage to keeping the idea of a
> "current figure" or "current axis" -- it's just not
> that hard to keep a reference. Maybe it does help for
> quickie command line stuff, but I think for even
> quickie scripts, it's clearer to name your axes, etc.
Agreed. I should rewrite all the examples and move the existing
examples into a "matlab-like" dir. The examples would all start with
the minimal import of figure, show, nx and close.
> However, the proof is in the pudding -- what needs to
> be done is for someone to sit down and start using
> MPL in interactive/quickie script use without pylab,
> and write something for OOlab whenever something is
> harder to do than it should be. Then we'll see how it
> works out.
No, one should just use pylab for figure creation and destruction and
add convenience methods to shorten some calls if needed, just as we
did when we added fig.savefig as a shorthad for
fig.canvas.print_figure on your suggestion. We don't need a new
interface though we could improve the existing one to handle some
annoyances. We do, however, want to use properties in the existing
interface.
Note also for the interactive use, we could probably utilize ipython
to call draw in special hooks.
Fernando: if one does
In[5]: o.set_something(blah)
can we configure ipython to do
gcf().canvas.draw()
iff o is an instance of a matplotlib.Artist?
JDH