Re: [Matplotlib-users] advice on writing an application

[Fernando P. <Fer...@co...>]

Matt Newville wrote:

> I think Fernando is not quite understanding the concern or complaint. 
> I also don't think anyone is 'hot' about it either.  And I know that
> Ken and I both "understand how free software works".  As it turns out,
> I'm mostly 'an algorithm developer' too and write open source
> applications that other scientists use as well.
> 
> Certainly IPython is very nice, and has an important niche -- I've
> even used it a couple of times myself.  The issue (for mpl) is that it
> may appear to be the "normal" way one uses mpl.  I do find that to
> similar to confusing python with IPython.  IPython is one way to use
> python, but it's not only way .... and it's not driving decisions
> about python.
> 
> For mpl, I believe that the 'make a wx mainloop for a command-line
> program' did drive some fairly ugly business in backend_wx.py that
> ended up making it harder to use backend_wx for GUIs.  I tried to
> patch this to be favor GUI writers, but the conflict was resolved in
> favor of the wx-mainloop-in-commandline.  I believe this may be fixed
> now.
> 
> More importantly, when discussing matplotlib the usage is generally
> given in terms of pylab, and often 'from pylab import *', which
> conveys the idea that matplotlib is intended for writing quick-n-dirty
> code.  And, as you can see from this discussion, the best way to use
> it in real GUI applications is not always well resolved <wink>.    So
> it is easy to conclude that pylab and ipython -pylab are given
> priority.
> 
> I stand by my concern about this, and  I think you're missing an
> important point if you easily dismiss the fact that Massimo's found
> this to be misleading.

OK, I don't have the time to get into a long-winded discussion here.  My 
simple point is that the reasons for the ipython/pylab presence in the public 
docs are mostly historical: over one year ago, I needed this, I wrote it and 
it got integrated (both mpl and ipython needed changes for this to work).  I 
should even add that I use Tk, not WX/GTK/Qt at all, so I could have lived 
without this support, but I figured that it would be a good thing to have a 
well-rounded interactive support.

Now, those using mpl as a library for handling plotting in GUI apps are 
becoming a growing group: I think that's GREAT!  I will probably benefit 
myself from these developments in the future, as I may need WX support for 
other things.

I am not _dismissing_ anything.  I am simply saying that if this is a need of 
a group of users, then the mechanisms exist to address it.  But saying that 
the docs 'have' to present one aspect vs another is, in a free software world, 
misplaced.  No free software project 'has' to do anything: it does what those 
writing the code make it do, end of story.

When 'pitching' mpl to other users, I always stress how the fact that it's a 
_library_ (instead of a program like gnuplot) is one of its greatest 
architectural assets.  While I personally don't use it as such (I could still 
get by with gnuplot and would be fine, given my needs), I use mpl because I 
like to know that, were I to need a more complex usage mode, the library 
allows me to do so.   So I am fully aware of the value and importance of this 
aspect of mpl.

To summarize: there's a need for easy, interactive plotting in python. 
ipython/pylab address that reasonably well.  There's also a need for easier 
usage of mpl in a more complex WX context: you guys are working on improving 
the situation here, and that's an excellent development.

The only sense in which the first aspect was given 'priority' was historical: 
we wrote that code over a year ago.  As your solutions mature and become 
publicly documented, I'm sure they will  be given equal space, since they 
address a _different_ problem than pylab/ipython do.  Not more important, not 
less important: different.


I'm afraid that this is drifting off-topic, so I'll probably close it here. 
It seems I wasn't very successful in clarifying a simple fact of the evolution 
of matplotlib I was involved with, without generating more noise than 
necessary.  Sorry about that.

Cheers,


f