>>>>> "Christopher" == Christopher Barker <[EMAIL PROTECTED]> writes:
Christopher> 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.
Christopher> Why couldn't plot(x,y) create and return a figure
Christopher> object? Or an axis object? -- I haven't thought it
Christopher> 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
Christopher> interface.
Christopher> Well, for *just* interactive use, I agree, but I see
Christopher> some very large advantages to an OO style for
Christopher> 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.
Christopher> As handy as it is to have a command line to play
Christopher> with, if I'm writing more than four or five lines
Christopher> (and I usually am!), I'm happier putting them in a
Christopher> file and running them as a script. Even in that case,
Christopher> I don't mind a little extra typing.
Christopher> What I'm envisioning for "OOlab" is a set of utility
Christopher> functions that do make some of the pylab stuff easy
Christopher> -- 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.
Christopher> F = ooLab.figure(1) # I often need to plot more than
Christopher> one figure anyway, so I don't mind having to type
Christopher> that.
Christopher> 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...
Christopher> ax.set_title = "A title for the plot" # or better
Christopher> yet: ax.title = "A title for the plot" # I'd like to
Christopher> see more properties in MPL too!
Agreed.
Christopher> ax.grid(True) . . .
Exists...
Christopher> Note that some of this comes from my love of
Christopher> namespaces -- I really don't like "import*" -- the
Christopher> way that can work is using more OO, so you don't need
Christopher> 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.
Christopher> I don't see much advantage to keeping the idea of a
Christopher> "current figure" or "current axis" -- it's just not
Christopher> that hard to keep a reference. Maybe it does help for
Christopher> quickie command line stuff, but I think for even
Christopher> 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.
Christopher> However, the proof is in the pudding -- what needs to
Christopher> be done is for someone to sit down and start using
Christopher> MPL in interactive/quickie script use without pylab,
Christopher> and write something for OOlab whenever something is
Christopher> harder to do than it should be. Then we'll see how it
Christopher> 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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
