A few comments:
John Hunter wrote:
I have no problem with this. I think we should agree on a standard
way of writing examples. I'm of two minds about how we should do this
vis-a-vis numerix symbols.
Approach 1: Help educate newbies about where symbols are coming from
import pylab as p
import matplotlib.numerix as nx
x = nx.arange(100.0)
y = nx.sin(2*nx.pi*x)
p.plot(x,y)
p.show()
Approach 2: Given that the array packages are still being reorganized,
use pylab as a namespace aggregator
import pylab as p
x = p.arange(100.0)
y = p.sin(2*nx.pi*x)
p.plot(x,y)
p.show()
Why use nx, rather than n? (or N, which is what I usually use). Actually, I usually use "import Numeric as N", I used Numeric long before I discovered matplotlib.
I'd say that this decision should be driven somewhat by what you want matplotlib to be. I see it as a plotting package, and I see Numeric (or SciPyBase?) as a numerical array package. Given that, option (1) is the way to go.
However, I can see the strong appeal of an all in one package, al la Matlab. If we go this route (which is kind of the route at the moment), we'll see lot of questions on this list that have nothing to do with matplotlib, and everything to do with Numerix. WE have that already, of course.
I really would like to see a nice, unified, set of packages for doing scientific/numeric work with Python. I think SciPy is the natural place for this, NOT matplotlib. My ideal version would have matplotlib as a sub-package of SciPy. It looks like we get to the grand-unification of Numeric, as SciPy Base, that that's a good start. I don't recall why you didn't make matplotlib a subpackage of SciPy in the first place, but I can understand that it happened that way, and honestly, there have been a lot of "plotting for SciPy" starts, and none of them has gotten to the usefulness of matplotlib, so you certainly did something right!
1 looks better to me for the standard symbols (arange, pi, etc...) but
when you start to include linear algebra, FFT, MLab, etc, I am not
sure. Currently mpl numerix uses the numarray hierarchy: is there any
advanced word on whether this will be used in Numeric3?
I haven't noticed, but I'm guessing it'll be something like:
import scipy.fft as fft
Basically, the question is, do we want to encourage using pylab as a
namespace aggregator to hide the complexity of where all these symbols
are coming from in packages whose organization is still evolving?
I'd say no, but you're point about the still evolving is a good one.
Also, I still want to support the 'from somewhere import something'
style of import since I think it makes the scripts more friendly to
read for many from a procedural programming background..
from pylab import hist, show
Sure. I do this a fair bit. I like it because it is explicit about where stuff is coming from. You're also right, if you are using a procedural style, typing "pylab." all the time gets pretty tiresome.
> One way to get there is to add much of the functionality of
> pylab to the OO interface. I really wish I had the time to
> write an OO-pylab, I think it would be really great, even
> for interactive use.
I think the OO interface is already pretty easy to use.
It may have gotten better. I haven't use it much recently, my main matplotlib using project has been handed off to another coder. I just remember that as much as I wanted to use the OO interface, It ended up being much easier to use pylab.whatever much of the time. Maybe the real problem isn't what's there, but what's in the examples.
* Easier attribute setting (eg x.facecolor = 'r') but this is
already accomplished somewhat since the set/get introspection
facilities are now available in matplotlib.artist to the OO user
I just looked in the class docs, and I still can't see how to set something in an OO way, like the facecolor, for example:
x.set('facecolor', 'r') maybe?
I know I'd rather x.SetFaceColor('r') or something like that, but the above is OK too.
* Have some way to enable auto-redraw on attribute change for
interactive use. This could be accomplished fairly easily with an
ipython hook
That would be nice. Having to call Figure.show() isn't too bad though.
* Make the backend figure canvas, figure import a little less wordy,
Yes. What I'd like to be able to do is:
import matplotlib as mpl
F = mpl.Figure()
A = F.plot(x,y)
A.xlabel("some text")
The only convenience you'd lose over the procedural interface is the "current figure/axis" concept, which I don't like much anyway.
Are there other areas you would like to see improved? There isn't a
lot pylab does anymore, except manage the figure windows. And
usually the API developer wants to do this in any case.
Well, yes, for embedded use, but for quick scripts and interactive use, there should gbe an OO way to have your figure windows managed.
It's probably time for me to put up or shut up...I hope I'll get a chance to put up soon.
Maybe a good start would be to go through the tutorial and users guide, and try to re-write all the examples in an OO manner, and see what happens.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@...259...
