Matplotlib For Python Developers

Craig Maloney writes "Ever since there was a collection of numbers, it seems that invariably someone will want a graph of those numbers. There are literally hundreds of different styles of graphs, and almost as many programs and tools to make those graphs. Matplotlib, a library and toolkit for the Python language, provides an easy and effective way to make some impressive graphics with little more than a smattering of Python. Matplotlib for Python Developers is equally impressive at distilling the core set of features of Matplotlib in a way that shows the reader how to get the most out the Matplotlib toolkit." Read below for the rest of Craig's review. Matplotlib for Python Developers author Sandro Tosi pages 291 publisher Packt Publishing rating 9/10 reviewer Craig Maloney ISBN 978-1-847197-90-0 summary A comprehensive overview of the powerful Matplotlib Python library Matplotlib for Python Developers begins with the customary introduction to the Matplotlib library. It includes where to download Matplotlib, as well as brief installation instructions for both Linux, Macintosh, and Windows platforms. The book then quickly moves to the next chapter, where the basic library functions are presented, via the interactive iPython shell. Each section of the chapter introduces a new part of the graph, with items like titles, grid lines, and labels being explained clearly and concisely. Also briefly presented are other useful libraries like numpy, as well as the various back-ends that Matplotlib supports. Chapter 3 continues the even pace, presenting more plot styles, and plot types, including polar graphs. These two chapters cover the fundamentals of Matplotlib very well, with each step clearly marked by what the graph should look like once completed.

The next chapter introduces more advanced plotting concepts that Matplotlib is capable of handling. The chapter begins with the three ways that Matplotlib may be used (The pyplot module, pylab, and the Object Oriented interface). From there, the book delves into subplots, multiple figures, additional axes, logarithmic axes, date plotting, contour plots, and image plots. Also included are sections on using LaTeX and TeX with Matplotlib, both for exporting graphs, as well as using TeX inside plots via Mathtext. By the end of the chapter, I felt very comfortable with the environment and the capabilities of Matplotlib, both as an interactive environment, and as a module for my own programs.

The next four chapters cover integrating Matplotlib with GTK+, QT4, wxWidgets, and web-based environments. The chapters for GTK+, QT4, and wxWidgets each begin by presenting a basic overview of the toolkit, and why one might want to use that particular toolkit. Next, the book shows how to embed a Matplotlib figure in a window, both with static and real-time data input. The book then shows how to use the toolkit's builder with Matplotlib (Glade for GTK+, QT Designer for QT4, and wxGlade for wxWidgets. The chapter on web development veers slightly from this format by showing several examples of using CGI and mod_python with Matplotlib before showing how to use Matplotlib with Django and Pylons.

The last chapter pulls together some "real world" examples together for the grand finale. The examples clearly show how Matplotlib would work for such plotting Apache web logs, fitting curves, and plotting geographic data. The geographic data plotting uses an additional module called basemap, which allows for plotting precisely on a map. This example floored me with the amount of power that Matplotlib possesses.

Overall, I found this book to be informative, without a lot of fluff. The organization of the book sometimes dipped into a chaotic presentation of "oh, look at this", but overall the author kept a very even pace, with clearly defined goals and clean resolution of those goals. Matplotlib for Python Developers is definitely a book that I would pick up to refresh my memory for using Matplotlib. The asking price is a bit steep for book that is just shy of 300 pages, but overall I highly recommend it for anyone looking to get started with this exceptional library. I'd also recommend it for anyone looking for alternatives to some of the other plotting packages available. Matplotlib is quite powerful, and Matplotlib for Python Developers makes this power very accessible.

You can purchase Matplotlib for Python Developers from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Why does everything need 250+ pages?

[Animats]

This is something that ought to be one chapter in a Python book, not another boat-anchor of a standalone book.

Re:Why does everything need 250+ pages?

[goombah99]

Matplotlib which I use a lot, has really sucky documentation so this 250 pages would amount to basically all the documents. Additionally, you have to realize that matplot lib is not one coherent entity. it's a mish mash of many many things in numberical analysis much of it having to manage legacy cases and pertending to ape matlab syntax. So there's lots of special cases to cover.

On the otherhand I really have ot wonder sometimes if matplotlib is a dead project. All of the standard distro's have 3D plotting that doesn't work anymore or depend on packages that are not maintained. The only modern 3d plotting in matplot lib is available through the enthought distro that folds in mayav. But since it does not support the full syntax of matplot lib and invents it's own new object structure, it's hard to write programs that one can distribute. Your end users may not be using enthought.

Mat plot lib is wonderful because it lets matlab users switch to python. But it sucks because it seems like it's not being maintained well.

Re:Why does everything need 250+ pages?

[ceoyoyo]

Yes, I have. The math stuff is just fine. The hardest part is usually installing LaTeX. The 3D stuff is unmaintained. There was some initial interest in it a few years ago and then it sort of died because there are other, better ways to plot in 3D. Even so, I believe the VTK integration still works reasonably well, and it just requires installing VTK and one other package. You might have a point that the third-party 3D addons to matplotlib are dead, but matplotlib itself certainly isn't.

The best way to distribute a Python environment is to tar the whole thing up and send it to whomever. An alternative is just to tar up the site-packages directory. For a long time I had a separate, easily accessible site-packages that could be packaged and distributed to everyone in the lab on a regular basis. On OS X you can even make a pretty double click installer in about five minutes.

*yawn*

[Anonymous Coward]

Wake me up when someone writes about Sillyplotadlib for Monty Python developers.

Python for Scientific use

[Thelasko]

I've heard quite a few people here on Slashdot talk about how useful Python is as a substitute for MATLAB. Honestly, I don't get it. Python is trying to be a language for both hard core programming, and scientific programing. These two disciplines have very different needs. I don't want to load 20 modules before I can begin coding. I just want to input my algorithm and get a result I expect (not 5/2=2).

It seems that version 3.0 has gotten better for us scientific users. However, I think the programmers out there are now dissatisfied.

Re:Python for Scientific use

[kolabaum]

I would consider Octave to be a much better substitute for MATLAB rather than Python for those who just wants to 'get the job done'. That being said, however, I think anyone who uses Python for scientific work (for whatever reason) would greatly appreciate Matplotlib due to the resemblance to MATLAB's built-in plot functions.

Re:Python for Scientific use

[fuzzyfuzzyfungus]

Does loading those twenty modules hurt you if, by virtue of their being in common use, there is some trivial automated way of doing it?

With the exception of people writing bare-metal assembly for microcontrollers or something, pretty much everyone who sits down to write some code has huge swaths of pre-written stuff loaded for them. The only difference is how much of that happens automatically, by default, and how much you see and do yourself.

If the science types happen to like python for some syntactic or structural or design reasons; but need a bunch of modules to make it do what they want, it isn't exactly rocket surgery to bundle them all together so a single "import science" does the job, or even hack together a slight variant of the python environment where that particular import is simply done silently by default.

Re:Python for Scientific use

[radtea]

I just want to input my algorithm and get a result I expect (not 5/2=2).

What result do you expect from 5/2? I expect 2... 5/2 == 2 in C, C++ and FORTRAN (I think... I don't write much FORTRAN code these days...)

Python does an excellent job of making both useful scientific functionality available via scipy and numpy and a wealth of other toolkits, and at the same time allowing us to package stuff up in usable applications. It provides all the real-world applications language facilities that MATLAB, Mathematica, R, etc lack.

I deal with people who "code" in those environments all the time, and they are not my peers: they have fundamentally failed to grasp almost everything important about programming, from design principles to documentation. For someone who knows how to write software--which MATLAB et al "programmers" do not, as a professional understands the term--Python is pretty much ideal for expressing algorithms and wrapping them in useful applications.

Re:Python for Scientific use

[0100010001010011]

Wake me when there is something even close to replace Simulink. Matlab is cool and all, but the real power of the program is Simulink.

Re:Python for Scientific use

[Helmholtz Coil]

That echoes my experience. I generally prefer Chaco for plots in Python since it seems to handle large datasets better than matplotlib (although matplotlib seems more functional), but matplotlib is comfortable for MATLAB users. I'm working on a SciPy project with a couple of MATLAB refugees and they love matplotlib.

Re:Python for Scientific use

[honkycat]

I use Python for scientific computing and much, much, much prefer it to MATLAB. Most of what I do does not require sophisticated library routines, and the sophisticated stuff I do need generally either aren't common enough to exist for MATLAB or are quirky enough that I wouldn't trust someone else's library to have the details right. Thus, the typically cited advantages of MATLAB are not there for me. Python provides a much better thought out programming language. It's sometimes a bit less convenient for interactivity, but really I got used to using it (plus matplotlib an numpy) quickly and I have not felt the urge to move back to MATLAB for quite some time. Very occasionally I'll pop in to do a crude curve fit, but not often.

The needs of scientific programming and hard core programming (whatever exactly that means) are not so different. As for not wanting to load modules, um, what? I can think of reasonable complaints about Python, but I don't consider that among them. That reeks of "it's different so I don't like it," which is not a well thought through reason.

Re:Python for Scientific use

[William Stein]

> I don't want to load 20 modules before I can begin coding. I just want to input my algorithm and get a result I expect (not 5/2=2). You might want to try Sage (sagemath.org and sagenb.org). It's Python, but it fixes the "5/2" issue and preloads numerous modules.

Re:Python for Scientific use

[matt_martin]

Not even quite sure MATLAB "does what it does well". Its usually a great way to get started, especially if you don't quite know what you are doing. But then I often find myself wondering why I am working around bugs and re-writing functions in a $10k software package. Moved almost everything to python/numpy/scipy/Matplotlib over a year ago and really haven't looked back.

Here's one thing that Matplotlib should not have replicated from MATLAB: insane memory usage.
Please folks, lets get it under control: 1G of memory to display a med-large image is a joke !

Re:Python for Scientific use

[WeatherGod]

What result do you expect from 5/2? I expect 2... 5/2 == 2 in C, C++ and FORTRAN (I think... I don't write much FORTRAN code these days...)

Just watch out in python 3.0, this will change. Because of python's duck-typing, you can never be certain if you were getting an integer or a float, and so it is possible to get different behaviors implicitly. Because python's mantra is "Explicit is better than Implicit", python 3.0 will only do integer (called floored) division when you do '//'.

Re:Python for Scientific use

[mangu]

I don't want to load 20 modules before I can begin coding.

That's why I don't like Matlab. Not only you have to import every single function you use, but each function comes in a separate file. And when you find the function you need on the web, you have to shell out an extra $5k to get the libraries it depends on.

My only worry about Python is that version 3 abomination. They not only managed to make each change towards a more complicated way to use, but also deprecated such a basic thing as string formatting. About one third of the code I write is related to text I/O, so a quick and easy way to format strings is very near the top priority on any language.

Last time I checked there are ten times as many references to the C language on Google as references to Python, so I cannot imagine why they want to get rid of the C-compatible string formatting. They created something that, in every single example I have seen, takes at least twice as much effort to write, offering no significant advantage.

If somebody needs a more sophisticated method for formatting strings, go ahead and create a new formatting library. But leave the true and tested way that has been working for nearly forty years alone. You cannot deprecate a basic functionality of a language just like that without dire consequences.

Re:Python for Scientific use

[Discrete_infinity]

Yes, I saw that and had similar thoughts. Also they should look at virtual environment and look at Interactive python

Re:Python for Scientific use

[BusterB]

When did they get rid of C-style string formatting? That's news to me.

bcook@bcook-box:~$ python3
Python 3.1.2 (r312:79147, Apr 15 2010, 15:35:48)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "%d %s" % (1, "Hello")
'1 Hello'

Re:Python for Scientific use

[pclminion]

That's exactly the output you should expect for integer division, which is what 5/2 is asking for.

On what planet? Just because C works that way, and Python works that way (at least until now), doesn't mean it's the best way, or the most useful way, or that it could never be changed.

That's EXACTLY the point being made here -- people are touting Python as a scientific computing platform, but the result "5/2 == 2" is almost never what you want when doing scientific calculations. So from the standpoint of scientific coding, some features are really not ideal.

Re:Python for Scientific use

[RichardJenkins]

Python 2.6.4 (r264:75706, Dec  7 2009, 18:43:55)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 5/2 #Diving integers in Python 2.6 gives an integer
2
>>> from __future__ import division
>>> 5/2 #Things work differently in the future
2.5
>>> 5//2 #You can use a double '/' to explicitly force an integer in Python 3
2

Re:Python for Scientific use

[Capsaicin]

Why are you anthropomorphizing?

Because it's a narrative device that can be used effectively to communicate. You didn't have any trouble understanding that "python" in that context stood for the python development community, did you? You didn't seriously think he was ascribing a human like intelligence to a language specification, did you? That anthropomorphism avoids clutter and actually increases readability, and after all, readability counts. :P

That being said, I have to agree with you. Part of the strength of python surely is its general applicability so effectively fostered by the SIGs. I'm not even sure what OP means by "hard core" programming. That's what C is for, no?

As far as switching over to float divisions by default, I thought that was meant to cut down on newbie bug reports ;) IOW, it's a little annoying to oldtimers (and the folks who regard integer division are the more natural) but probably obeys the principle of least surprise for most naive programmers out there.

Re:Python for Scientific use

[brunos]

Hi, I see your point: Python is getting a lot better for scientific use, maybe not so much due to the changes in 3.0 but rather because the community has grown (e.g. Python(x,y), Enthought). There are a few things that make Python what I use most of the time for scientific work: - The language is better thought out i.e. the Matlab tradition of having one function per file is just annoying. - The quality of the old Fortran algorithms which scipy wraps is consistently better than that of Matlab functions e.g. Matlab fitting routines are a mess, I get much more accurate results with scipy. - Compatibility between versions: matlab code from my colleagues always needs some work to run: either because there have been some changes between matlab versions, or they use a function from a toolbox that I don't have, even though there is an equivalent one in standard matlab. Since we changed to Python all is fine. - When you cannot vectorize a small piece of code, scipy offers a few ways in which compiled code can be added transparently: cython, pyrex, f2py and even pycuda. Much easier than .mex in matlab. - Python has a large set of very useful libraries for doing scientific work e.g. networkx, vpython ... - Thanks to Python's large set of other libraries, it is trivial to do things such as parsing complex files, interfacing with lab equipment (pyvisa, ...) interfacing with the windows/linux/mac GUIs, using databases, sending data over the network etc. All these things are really handy in the lab. - I don't mind paying for software, but the license management is really a problem: It has happened quite a few times, that Matlab has stopped working because something in the license management had changed. Loosing a day of work of a research group is expensive. - Of course, the fact that students can just install Python for free, and maybe use it in their future non-scientific job is a plus.

Try Veusz for an easier life

[xiox]

If you find matplotlib hard, try my Veusz python plotting package. It has a GUI you can build plots within. It is scriptable in python, and even the saved file format is a python script to generate the plot. It can read a variety of data formats.

This book claims publication quality plots...

[yerM)M]

It's too bad they didn't use any in the book.

I have used matplotlib for journal plots and actually gave away a copy at a conference I ran so I have to say I really do like the book overall, but if you scan through the pages, you might be turned off.

In Defense of Matlab

[tobiah]

Python has it's strengths, but there are good reasons Matlab is so widely used:

Price: There is a price to everything, Matlab's is up-front and what you get is guaranteed support and development. If there is a bug or serious shortcoming you know someone is working on it like their job depends on it.
Graphics: Matlab has the most feature-rich and usable graphical environment of any of its would-be competitors, none of which do 3D well.
Speed: Core Matlab operations are highly optimized in C; properly vectorized Matlab code will run much faster than what most programmers could write in C themselves.
Interoperability: Java and .Net calls can be made from the Matlab command line, integrating compiled C is well-supported and very straightforward. Python can do these things, but it's not automatic or well-documented.
Documentation: it's there, and it's good.
Dev Environment: the debugging tools, profiler, and lint integration are really helpful.

Re:In Defense of Matlab

[Vireo]

Speed in interpreted languages such as Python and Matlab depends strongly on what it is doing exactly, and how it is done. For example, both Matlab and the numpy Python module use external, pre-compiled, and highly optimized basic linear algebra subroutines (BLAS) for things like matrix multiplication. Matlab ships with several different BLAS, but it's even possible for Matlab to use the ATLAS BLAS which numpy uses.

So the speed would be the same in that case, assuming both your Matlab installation and numpy are configured to use the same number of processors (linear algebra is typically highly parallel, and in huge matrix operations, multi-thread overhead will be negligible).

If you code your own matrix multiplication naively in C, you may end up with a factor of 6 or 7 in speed *below* that of Matlab.

However if we're talking about generic loops for example, C is then much, much faster. Matlab has a Just-in-Time (JIT) optimizer which vectorizes straightforward loops; the same for Python is not ready yet (this would be the Unladen Swallow project from Google I think). Depending on the precise morphology of a loop, very different speeds would be obtained in Matlab, C or Python. The lesson here is to use numpy or scipy precompiled and pre-optimized code whenever this is possible. But when it's done right, there's generally much less difference between Matlab, Python and optimized C than many people think.

Re:In Defense of Matlab

[Vireo]

A few quick comments on this well-informed post...

Price: you're right here, Matlab is expensive and is locking you down, but at least you get very decent support from The MathWorks.

Graphics: Matlab has a huge library of very usable graphics functions. However it is nonetheless lacking in certain areas. GUIs is one of them (you can only embed Matlab graphics in a Matlab GUI, and the various methods to build a GUI in Matlab mostly sucks compared to what is possible outside of Matlab). Also, while Matlab figures exported to other format (PDF, EPS, bitmaps) are fine, on-screen Matlab figures are not anti-aliased and sometimes present quirks that are not really there. Matplotlib uses the Antigrain library for screen output, so the end result is much more pleasing to the eye.

Speed: Using numpy, you benefit from the binary linear algebra subroutine (BLAS) speed, much as Matlab. Generic loops tends to be slower than Matlab because of Matlab's Just-in-Time (JIT) optimizer.

Documentation: I'll give you this one hands-down: Matlab has *excellent* documentation, written by experts in the field. This is an often neglected area, but clean and profuse documentation and examples allows you to do more things, much quicker.

Dev environment: very good in Matlab, but using any Python syntax-aware text editor + the IPython shell, I don't miss much when developing Python. Python is generally more consistent (e.g. you can define a multi-statement function interactively in the Python shell), which speeds up development. Also, Matlab is beginning to feel a namespace crunch. All functions in all toolboxes are in the same namespace in Matlab, and it's beginning hard to find creative new names for my own function, all the most if they replicate some Matlab's built-in capability. Python's namespace / module imports solves this problem very nicely.