advice on writing an application

Hey, I didn't want to start a flamewar on all this!
Please breath! :slight_smile:

  >>My take on things is that WxMpl and MPlot solve two different problems.

Here's how I do see things now, based on your descriptions:

- pylab is made for pure interaction or quick-and-dirty (but
nevertheless useful) scripts for interactive data analysis
- MPlot is thought "in between", for advanced scripting or simple
programming: it allows the end user to do quite complex things with not
so much programming and other users of the script to interact with the
plot, giving up some strict programming flexibility.
- wxMpl is thought for programming: it requires knowledge of WxWidgets,
a bit more abstraction and careful thinking from the programmer, but it
gives maximum flexibility.

Note that I said "is thought", not "is made only for": it is surely
possible to script with wxMpl and to do advanced programming with MPlot.
I just want to understand the objectives of the three projects.
It is true in your opinion?

Well, that and the fact that to use wxMPL you have to understand
matplotlib. Like, that
a figure has an axes, and axes has 'plot()' and 'imshow()'.

Well, I see nothing really bad in it. To fully use the power of a
library, I guess you should understand how does the library works, or at
least what its APIs are.

I wrote WxMpl after Matt sent me MPlot 0.7 because I felt that his approach
wasn't solving my problem: I was thrilled what matplotlib and wanted *all* of
it to Just Work with wxPython.

I think it would be much better for everyone if we could work on a
single solution and I was pretty disappointed when I showed you what I
had and you went off and wrote something else that fills very many
similar niches. I'm sure MPlot is not as fancy or subclassed as
wxMPL, but having a common wxPython plot control based on matplotlib
that was easy to use and just ready to plug into an application would
be better for everyone, I think.

  >[...]
  > I understand that for _you_ a library that wx-dresses
  > matplotlib is OK, but why not try to have a good feature-rich plotting
  > package for wxPython?

I have only tried a little wxmpl, and still didn't try MPlot, but I was
wondering: can MPlot be rewritten using WxMpl?
In this way we wouldn't have to "choose" and to fork the goal of a
unified wxPython/MPL solution. Instead, we would have a flexible stack
of solutions at different levels. WxMpl would stay less or more as it
is, providing a quite low level interface for people who need/like it (I
feel I'm among these people, although it's still very possible to change
my mind). On top of it, MPlot would extend WxMpl, creating advanced
wrappers and controls to ease things for who needs "intermediate"
scripting (a need that I think is very real). And possibly in future
Pylab would stay on top of this stack, using MPlot and WxMpl to deal
with interactive plotting.

Allowing users to edit plots was less important to me than supporting as many kinds of
plots as possible.

Really? I find this hugely important. For mapping, it will be vital
to allow the user to adjust contrast and change color maps, where
user-driven changing of data value -> display is critical for
understanding the data.

Well, it depends on the data you're using and on what you're doing. For
the work I'm planning, I don't need all of this: I'd prefer integration
into an application and full MPL support.
But it's true that there are situation in which you badly need something
like that. I think the "stack" solution can be an idea.

Yes, provided you know matplotlib. Which is, to be fair, kind of
quirky. I mean is all of
    app = MyPlotApp()
    figure = app.get_figure()
    axes = figure.gca()
    axes.plot(x,y)

really necessary? I've seen the matplotlib code, and have used a
fair number of plotting libraries in my day. The matplotlib results
are wonderful, but the API is a bit goofy, don't you think? Does
FigureCanvas->Figure->Axes make sense to you? I'd be OK with two of
those, but I don't understand how three possibly helps.

I think having the 'privilege' to deal with object properties is good in
the end for the programmer, although it can be confusing for the noob.

I'm also really very concerned about the priority given to pylab and ipython.

I'm really concerned about it too. As a MPL newbie, I found it very
misleading. I'd like to see a full programming stack on top of MPL, with
pylab, MPlot and wxMpl being integrated components of it, and with a
nice documentation about it.

As I said earlier, I think we're trying to solve different problems. I do want
to use the low-level matplotlib API, because it's a more flexible and
powerful. If necessary, I want to be able to say in a wxPython program "make
a wxPlotter and then make two subplots, one a line plot with two embedded
axes, the other a histogram and a line plot, and then chain their X axes
together".

How often do you actually do this? Does it need a library? I'd
guess 80% of the results could be had with a much higher-level
interface. A grid of multiple plots is certainly possible by packing
panels together. I don't use histograms or bar graphs much myself,
but these would be trivial to add to something with a more MPlot- (or
if you like, more BLT-)like interface.

You have different needs. I feel next to the needs of Ken, but for
example my desktop neighbour here that does AFM imaging would feel on
the side of Matt. It is useless to say "how often do you do this?",
because you don't know what my needs are. I think a scientific library
should be as much general and agnostic as possible.

I think you may be in the mindset of a library-writer where 'user' is
an application developer. The question was about writing applications,
and there User is the person running the program. They care 0% about
the cleanliness of the API, but if the fonts too small or they change
the red solid line to blue dots, the program sucks.

I think the user wants to see a good program. I think the programmer
(that sometimes is the user, sometimes is not) has the responsibility to
care about usability details, not the user. So if the fonts are too
small, it's a problem that the programmer must solve. I'm all for
configuration (I hate people that say "configurability confuses users")
but it can be embedded in, let's say, a .myplotrc. But that's my
opinion, and I understand you want more direct user interaction, instead.

I understand you felt disappointed when you did MPlot and your friend (I
hope you're friends) went away and did something else. I think simply
you should try to collaborate to fit both niches in a coherent stack,
instead of competing for the wx and MPL union.

Massimo

路路路

--
Massimo Sandal
University of Bologna
Department of Biochemistry "G.Moruzzi"

snail mail:
Via Irnerio 48, 40126 Bologna, Italy

email:
massimo.sandal@...898...

tel: +39-051-2094388
fax: +39-051-2094387

Hey, I didn't want to start a flamewar on all this!

It's not a flamewar! Matt and haven't began maligning each other's ancestry yet! :slight_smile:

I just want to understand the objectives of the three projects.
It is true in your opinion?

I'd say you've got it right.

I understand that for _you_ a library that wx-dresses
matplotlib is OK, but why not try to have a good feature-rich plotting
package for wxPython?

I have only tried a little wxmpl, and still didn't try MPlot, but I was
wondering: can MPlot be rewritten using WxMpl?

It certainly could. WxMpl could take care of the basic user interaction stuff (e.g. zooming), leaving MPlot to focus on plot editing features.

But it's true that there are situation in which you badly need something
like that. I think the "stack" solution can be an idea.

I really like the idea of stacking the different levels of abstraction on top of each other. It would allow us to reduce code duplication without limiting what application developers can do with matplotlib.

I'm also really very concerned about the priority given to pylab and ipython.

I'm really concerned about it too. As a MPL newbie, I found it very
misleading.

I haven't really given it much thought. Most people presumably use MPL from IPython or scripts via pylab, so focusing documentation efforts on it make sense. I think that getting a good OO API manual would really improve things for application developers, but might be hard to justify in the big-picture.

Ken

路路路

On 12/02/05 04:54, massimo sandal wrote:

massimo sandal wrote:

I'm also really very concerned about the priority given to pylab and ipython.

I'm really concerned about it too. As a MPL newbie, I found it very
misleading. I'd like to see a full programming stack on top of MPL, with
pylab, MPlot and wxMpl being integrated components of it, and with a
nice documentation about it.

Chill out, there is no dark plan here :slight_smile: It's simply a matter of usage patterns: my personal audience is one of other programmers, I'm mostly an algorithms developer and the code I write is used by other mathematicians, physicists, etc. to write programs. Hence, command-line, interactive use is _my_ priority, and I did the work (along with John's and others' help) to make sure that mpl would work as well as possible in this context. I have currently no need to write GUIs, so I haven't worked on that. Others also liked these capabilities, and contributed for example the interactive Qt support.

I think it's great that a nice set of OO, high-level tools is being developed for MPL with WX, I may even need those in the future. If others need similar Qt or Tk-based tools they may also develop them, which is great as well.

You need to understand that this is simply how free software works: when someone needs something badly enough _for themselves_, they get off their butt and write it. Then it's available for all to use (if released). I did that for interactive mpl support over a year ago, so that's why it's been prominently displayed for a while (and this _is_ useful to a lot of people, since quick-and-dirty interactive data analysis is a very common task). Now you guys are doing the same for WX tools, and that's fantastic. I'm sure John will advertise it equally prominently.

So relax, nobody is trying to be misleading about anything, we're all here simply working on what each of us needs, so the evolution process is rather inhomogeneous.

Cheers,

f

Ken McIvor wrote:

I haven't really given it much thought. Most people presumably use MPL from IPython or scripts via pylab, so focusing documentation efforts on it make sense.

Not really. Most people use pylab, because that's what's well documented, not the other way around. Also, a lot of us have matlab experience, so pylab is easier that way.

That being said, I don't like it much, I'd much rather have a nice, pythonic interface. I don't see any reason that a good OO API couldn't be just as effective for quick scripting as the current pylab one.

I'd be happy not to have to keep track of which is the current axis, and keep having to call gca() and friends.

> I think that getting a good OO API manual would really

improve things for application developers, but might be hard to justify in the big-picture.

I think application developers are a big part of the big picture, in fact.

I had the idea of writing a version of the MPL manual using all OO syntax. I'd still like to do that. It would provide a useful document, and be a good test bed for what features really are miss or are more awkward to do with an OO style. Maybe one of these days I'll actually work on it!

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...

Chris,

Christopher Barker wrote:

Ken McIvor wrote:

I haven't really given it much thought. Most people presumably use MPL from IPython or scripts via pylab, so focusing documentation efforts on it make sense.

Not really. Most people use pylab, because that's what's well documented, not the other way around. Also, a lot of us have matlab experience, so pylab is easier that way.

Don't understimate the importance of this group of users, present and potential. For a lot of people doing a lot of things, the Matlab/pylab approach works very well. Sometimes OO programming is a good way to go, but it is not the best approach in all cases. One of the strengths of python itself is that it works fine with or without OO style; mpl brings that strength to 2D graphics.

Eric