On 2/27/07, Christopher Barker <[EMAIL PROTECTED]> wrote:
> Or even more - not use pylab at all. There is nothing inherent in OO
> design that makes it necessary to write a bunch more code. It would be
> nice if the OO interface were just as easy to use.
I don't agree with this at all. Inherent in OO design is object
creation, attribute setting and method calling. pylab automates some
of these steps, which in any OO design can be a little repetitive, via
figure management and current axes handling. Consider this current
use case of pylab
> ipython -pylab
>>> plot([1,2,3])
A figure window pops up and a plot appears inside an axes. My belief
is that try as you might, you won't create an object oriented API
which mimics this ease of use. Let's say you are willing to grant
pylab (or whatever you call your favorite API) control of managing of
the current figure via use of a 'figure' call. Then you can simplify
this to
>>> fig = figure()
>>> ax = fig.add_subplot(111)
>>> ax.plot([1,2,3])
OK, that's not too bad and is how I work on a daily basis, but it is
still considerably more typing. So let's grant automatic current
Figure creation to the API. We'll retain control of creating the
Axes, but if there is not a Figure window to put it into, we'll
automatically create a Figure to hold it. Then we have something like
>>> ax = subplot(111) # automatically create a Figure to hold the Axes
>>> ax.plot([1,2,3])
That's only a little more work (and is supported with 'from pylab
import subplot'), but why do we have to manually instantiate the Axes
with 'subplot', let's autocreate it if it isn't there. Ok, let's make
a function 'plot' that will plot into the current Axes if it exists
and create one if it isn't there (and by implication create a Figure
if it isn't there)
>>> plot([1,2,3])
OK, that's nice and easy, but we just reinvented pylab 'plot', which
really does nothing except manage the current Axes and Figure and
forward the rest on to Axes.plot. pylab does nothing except manage
the boiler plate that comes from using an OO framework -- basically it
automates object instantiation and method calling by inferring which
objects you want to create and which objects you want to forward the
method calls to. And in my opinion, it does so pretty well.
In an OO framework, this process of inference and forwarding is
prevented by design, and hence you have more work to do on the user
end, usually for good reason. I believe there is a tradeoff between
having explicit control -- managing axes and figures and explicitly
designating which objects get the attribute assignments and method
calls -- and convenience. pylab trades explicit control, which is not
to say it trades control, for less boilerplate code and more
convenience. pylab is a state machine -- it manages the current
figure and axes and forwards calls as appropriate to the active object
-- and state machines have proven very useful in other programming
paradigms, For example, the postscript and opengl languages are both
state machines, not object oriented languages, and both are very
useful for creating graphics,
The point of this exercise is that you can make the API progressively
easier to use by providing helper functions, but in the end, you'll
rewrite pylab or something like it. In my experience, save for a
little boilerplate for figure and axes creation, and the occasional
verbosity of some getters and setters, the current OO API is pretty
easy to use.
The one thing that is clearly more verbose than it needs to be to me
is the use of the setters and getters. One wants to do
o = ax.text(1, 2, 'hi Chris')
o.color = 'black'
rather than
o = ax.text(1, 2, 'hi Chris')
o.set_color('black')
and we could implement that fairly easy, saving five keystrokes.
Probably the reason there is limited impetus to do so is that it is
even easier (and less typing) to use keyword args in the current API
(and in pylab since pylab just forwards them to the API)
ax.text(1, 2, 'hi mom', color='black')
and in fact using multiple kwargs is a good bit less typing than using
multiple properties. Eg, the following which you can do currently
ax.text(1, 2, 'hi mom', color='black', size=14)
is a good bit easier than
o = ax.text(1, 2, 'hi Chris')
o.color = 'black'
o.size = 14
and so on.
You've made the point about the API being hard to use many times, and
at least once you've made specific suggestions (eg adding
Figure.savefig) which we've implemented and I which find quite
useful. I suggest you start a wiki page on the matplotlib Cookbook
site listing the problems you see with the API and specific things you
would like to see changed, so the discussion can be more productive.
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
