John Hunter wrote:
> On 2/27/07, Christopher Barker <[EMAIL PROTECTED]> wrote:
>> There is nothing inherent in OO
>> design that makes it necessary to write a bunch more code.
>
> 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.
OK, maybe there is inherently a little more code in an OO framework, but
the case at hand was perhaps 4 lines of code wrapped up in a pylab
function -- that could just as easily be 4 lines of code in a matplotlib
class method.
Also, I think there is a distinction between talking about "functional
vs. OO" and the automated figure and axis management.
For example, the standard way to manipulate objects with a functional
interface is something like:
Afunction(AnObject, TheParameters)
in OO, it's:
AnObject.TheMethod(TheParamerters)
Exactly the same amount of typing, but I think the later is cleaner.
As far as pylab goes, the introduction of state: current axis and
current figure, lets you avoid specifying the object you want to act on,
so yes, you do save some typing there.
However, I do think that it would be possible to make a nice OO
interface for interactive use -- perhaps that would mean keeping a
current figure and axis, and I think with auto generation, we could get
close:
> >>> 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.
It is nice to have a really simple plot command. What would it do if we
were trying to be fully OO? My key question is whether it would return
and axis, a figure or both:
Fig, ax = plot([1,2,3])
then:
ax.xlabel("whatever")
isn't bad for me.
> 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.
Yes, it does, and it does have key advantages for interactive use. I
think where my opinions come from is two key points:
1) I never really do all that much interactively -- I used Matlab for
years, and now Python for years. In both cases, I write maybe a few
lines to test things interactively, but if I'm writing more than 3 lines
or so, I write a small script -- one that I'm likely to want to paste
into a larger code base at some point.
2) the pylab interface really does get in the way and make me less
productive for larger bodies of code.
So I want ONE interface, and I want it optimized for large code bases,
but still simple enough to not be painful for small scripts and
interactive use.
> 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.
I agree. I think we are close. This thread started because it was
suggested that some code put into pylab be moved into the axis class (I
think it was the axis class) so that OO users could have easy access to
that functionality too.
> The one thing that is clearly more verbose than it needs to be to me
> is the use of the setters and getters.
Agreed.
> 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.
True, but what about:
ax.xlabel="a label"
and the like. I like properties -- they feel Pythonic to me.
> 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.
Good idea. I've always intended to contribute more. I've mostly been
waiting for a project where I'm really using MPL enough to know what I
need. I've got one coming up, we'll see.
Meanwhile, I use a far too much time kibitzing on mailing lists...
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
[EMAIL PROTECTED]
-------------------------------------------------------------------------
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
