In article
<8b2d7b4d0901050152p4c7487a8m21fb7fb823297f3d@...288...>,
Hello and Happy 2009!
I received the interesting proposal to author a book on Matplotlib,
the powerful 2D plotting library for Python.
While preparing the arguments list, I'd like to hear even your
opinion, because different points-of-view will lead to a better
product.
Some basic question I'd like to ask are:
- what are you using matplotlib for?
Plotting data from a networked Tkinter application.
- what are the (basic) things that, when you were beginning to use
matplotlib, you wanted to see grouped up but couldn't find?
- what would you like to see in a book about matplotlib?
I want a user's guide for the class API. So far I've figured it out by
reading examples, trying to extrapolate from the pylab user's guide
(which is quite good) and reading the class API reference, but I feel
that I barely understand what I am doing.
- what are the things you'd like to explore of matplotlib and never
had time to do?
I'd like to know how best to handle plotting data as it arrives (e.g.
strip charts and evolving x-y plots). I've got code that works but am
not convinced I'm doing it in the best fashion.
Histograms.
-- Russell
···
"Sandro Tosi" <morph@...10...> wrote:
Hello Russell,
thanks for getting back to me
In article
<8b2d7b4d0901050152p4c7487a8m21fb7fb823297f3d@...288...>,
- what are you using matplotlib for?
Plotting data from a networked Tkinter application.
May I ask you to expand a bit what "networked" is? something like:
read data from a remote server and plot on the client? Just to have an
idea 
- what are the (basic) things that, when you were beginning to use
matplotlib, you wanted to see grouped up but couldn't find?
- what would you like to see in a book about matplotlib?
I want a user's guide for the class API. So far I've figured it out by
reading examples, trying to extrapolate from the pylab user's guide
(which is quite good) and reading the class API reference, but I feel
that I barely understand what I am doing.
The idea of the book is to start with simple plots, describing the
methods we call and how they work, to go into more details along the
book.
- what are the things you'd like to explore of matplotlib and never
had time to do?
I'd like to know how best to handle plotting data as it arrives (e.g.
strip charts and evolving x-y plots). I've got code that works but am
not convinced I'm doing it in the best fashion.
I already thought about an examples of "plotting with data changing on
time" like plotting the cpu usage or so, so it might be useful to you
that too
Histograms.
If there's something particular interesting for you, it would be
helpful to me to know it
Cheers,
···
On Mon, Jan 5, 2009 at 20:29, Russell E. Owen <rowen@...1342...> wrote:
"Sandro Tosi" <morph@...10...> wrote:
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Sandro Tosi wrote:
The idea of the book is to start with simple plots, describing the
methods we call and how they work, to go into more details along the
book.
I suggest that you focus on the OO interface, rather than the pylab interface from the beginning. This will ease the transition from command line use to embedding, help folks understand the structure of MPL, and is the "right" way to do it (IMHO) with an OO language anyway.
-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
Chris.Barker@...259...
So you suggest to start from matplotlib.pyplot and not from pylab?
Well, sure it's an interesting point-of-view. I'll reflect about your
proposal.
Thanks!!
···
On Tue, Jan 6, 2009 at 00:20, Christopher Barker <Chris.Barker@...259...> wrote:
Sandro Tosi wrote:
The idea of the book is to start with simple plots, describing the
methods we call and how they work, to go into more details along the
book.
I suggest that you focus on the OO interface, rather than the pylab
interface from the beginning. This will ease the transition from command
line use to embedding, help folks understand the structure of MPL, and is
the "right" way to do it (IMHO) with an OO language anyway.
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Sandro Tosi wrote:
So you suggest to start from matplotlib.pyplot and not from pylab?
actually, I think matpoltlib.pyplot still has all of pylab in it, just not all of numpy also. So yes, do that, but what I meant was to focus on using the OO interface, rather than the state machine interface:
rather than 'gca', 'gcf', etc, store references to the figures and axis, etc:
this kind of thing:
fig = plt.Figure()
ax = fig.add_subplot(111)
ax.plot([1,2,3])
ax.set_title('hi mom')
ax.grid(True)
ax.set_xlabel('time')
ax.set_ylabel('volts')
While we are at it, discourage the use of "import *" !
-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
Chris.Barker@...259...
Sandro Tosi wrote:
So you suggest to start from matplotlib.pyplot and not from pylab?
actually, I think matpoltlib.pyplot still has all of pylab in it, just not
all of numpy also.
yes, pylab glues pyplot and numpy together
So yes, do that, but what I meant was to focus on using
the OO interface, rather than the state machine interface:
rather than 'gca', 'gcf', etc, store references to the figures and axis,
etc:
this kind of thing:
fig = plt.Figure()
ax = fig.add_subplot(111)
ax.plot([1,2,3])
ax.set_title('hi mom')
ax.grid(True)
ax.set_xlabel('time')
ax.set_ylabel('volts')
Ahhh ok, now I got it: I always use the style above, so I didn't know
the difference A reference to the doc is:
http://matplotlib.sourceforge.net/faq/usage_faq.html
While we are at it, discourage the use of "import *" !
Absolutely!
Your suggestions were really precious: please don't stop the stream,
it anything comes up
Cheers,
···
On Tue, Jan 6, 2009 at 01:48, Christopher Barker <Chris.Barker@...259...> wrote:
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
I suggest that you focus on the OO interface, rather than the pylab
interface from the beginning. This will ease the transition from command
line use to embedding, help folks understand the structure of MPL, and
is the "right" way to do it (IMHO) with an OO language anyway.
+1
I think many people will want to move from command-line stuff to
embedding in the end. I've been a number of users attempt to embed mpl
figures using the pylab interface and it always ends in frustration...
The OO-interface get less attention in the documentation/examples. It
would be good to address this.
BC
···
-Chris
Hmm, if people are trying to do this, it does does point to an absence
of adequate documentation because for years we've been saying on the
lists that for years that you should not attempt to embed pyplot in a
GUI. I'll make a FAQ.
JDH
···
On Tue, Jan 6, 2009 at 6:06 AM, Bryan Cole <bryan.cole@...490...> wrote:
I think many people will want to move from command-line stuff to
embedding in the end. I've been a number of users attempt to embed mpl
figures using the pylab interface and it always ends in frustration...
John Hunter wrote:
I think many people will want to move from command-line stuff to
embedding in the end.
Hmm, if people are trying to do this, it does does point to an absence
of adequate documentation because for years we've been saying on the
lists that for years that you should not attempt to embed pyplot in a
GUI. I'll make a FAQ.
A FAQ is a good idea, but the real problem is that most of the docs, examples and code on this list has been matlab-style. People are going to follow examples far more than any amount of documentation.
It seems there is an effort to establish a new "standard" style for example, etc, which will help a lot.
-CHB
···
--
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
Chris.Barker@...259...
Christopher Barker wrote:
A FAQ is a good idea, but the real problem is that most of the docs,
examples and code on this list has been matlab-style. People are going
to follow examples far more than any amount of documentation.
I agree. I tend to learn by example with less resistance.
Dear ALL,
2009/1/6 Christopher Barker <Chris.Barker@...259...>:
A FAQ is a good idea, but the real problem is that most of the docs,
examples and code on this list has been matlab-style. People are going
to follow examples far more than any amount of documentation.
I fully agree. Matplotlib examples, available tutorials, and official
documentation seems too much directed towards presenting it as an
alternative to Matlab, although the library much more flexible and
powerful than "just that".
Cheers,
···
--
Dr. Mauro J. Cavalcanti
Ecoinformatics Studio
P.O. Box 46521, CEP 20551-970
Rio de Janeiro, RJ, BRASIL
E-mail: maurobio@...287...
Web: http://studio.infobio.net
Linux Registered User #473524 * Ubuntu User #22717
"Life is complex. It consists of real and imaginary parts."
I don't think this is really true anymore -- practically every example
I've written and posted in the last two years has been using the API,
with pyplot just used to generate the figure and show. And most of
the chapters I've written for the online docs, excepting the pyplot
tutorial, have done the same
http://www.nabble.com/user/UserPosts.jtp?user=93644&local=y&forum=2903&matchingForums=a
http://matplotlib.sourceforge.net/users/artists.html
http://matplotlib.sourceforge.net/users/event_handling.html
http://matplotlib.sourceforge.net/examples/animation/index.html
http://matplotlib.sourceforge.net/examples/api/index.html
http://matplotlib.sourceforge.net/examples/event_handling/index.html
http://matplotlib.sourceforge.net/examples/user_interfaces/index.html
JDH
···
On Tue, Jan 6, 2009 at 11:59 AM, Mauro Cavalcanti <maurobio@...287...> wrote
I fully agree. Matplotlib examples, available tutorials, and official
documentation seems too much directed towards presenting it as an
Great stuff.
Note that the final figure is truncated on the right.
Alan Isaac
···
On 1/6/2009 1:27 PM John Hunter apparently wrote:
http://matplotlib.sourceforge.net/users/artists.html
Great discussion.
I think this tangent indicates a need for a section to explain both the
history of pylab, matplotlib.pyplot, and how they relate. (I'm still
confused at what exactly the difference is.)
My perspective is that of a scientist doing numerical analysis who needs to
visualize computational results and compare it to experimental data. I
normally don't have time to get into the interesting computer science
essoterica: what I need are
- a toolkit of HOWTOs;
- a solid reference to the various classes and functions; and
- a comprehensive index.
I also echo the request for a consistency in style: e.g., always use the OO
style as a basis, *supplementing* (i.e., duplicating) with a MATLAB-style as
needed.
When doing dev and programming work in python, I find myself constantly
refering to Martelli's "Python in a Nutshell" (2nd ed., but often using the
index from the 1st ed. because it's soooooo much better). At times I also
find Martelli & Ascher's "Python Cookbook" invaluable. I think that a good
reference to functions with liberal use of code snippets, combined with a
chapter of short cookbook examples, would be most useful for the Matplotlib
book.
Tell the gent who floated you the proposal that I'm looking forward to
purchasing the book. Oh, and please hurry up with the publication!
James
···
On Monday 05 January 2009 17:48:43 Christopher Barker wrote:
Sandro Tosi wrote:
> So you suggest to start from matplotlib.pyplot and not from pylab?
actually, I think matpoltlib.pyplot still has all of pylab in it, just
not all of numpy also. So yes, do that, but what I meant was to focus on
using the OO interface, rather than the state machine interface:
rather than 'gca', 'gcf', etc, store references to the figures and axis,
etc:
this kind of thing:
fig = plt.Figure()
ax = fig.add_subplot(111)
ax.plot([1,2,3])
ax.set_title('hi mom')
ax.grid(True)
ax.set_xlabel('time')
ax.set_ylabel('volts')
While we are at it, discourage the use of "import *" !
-Chris