Matplotlib Gallery | Hacker News Reader

Matplotlib Gallery

matplotlib.org

83 pointsbelter26 comments

Great library with what may be the most unintuitive, patched-together feeing api of any charting library I’ve used.

Agreed. I did not understand how terrible it is until I tried R's ggplot2.

ggplot and matplotlib have drastically different purposes. Ggplot is for statistical plots (see seaborn which is built on top of matplotlib for another style of statistical plots library). Matplotlib has multiple interfaces you can use and modern matplotlib code is very consistent and nice to use *if you need full control over your plots* (and it does way more than just statistical plots). The older matplotlib interfaces are indeed a bit of a mess, due to historical reasons.

See bokeh (in python) and makie, gadfly, plots, and AlgebraOfGraphics (in julia) for yet more styles of making high level plots. But again, matplotlib targets users needing more control and less statistics (people build stats and other libraries on top of matplotlib though).

If you need full control over your plots, you should just d3, which an insanely sane interface compared to matplotlib

That is a pretty terrible suggestion. D3 is wonderful, but it is just clunky to use for the engineering type of plots matplotlib excels at. And the learning curve for D3 is absolutely brutal compared to matplotlib. And D3 requires JavaScript (can you even get an arbitrary-DPI PNG or a high quality EPS/PDF with D3?)

Matplotlib is like democracy, the worst option except all the other options. I do production quality plots for technical reports and matplotlib is the only suitable python library I've found that gives me the control I need. Like you say, there are lots of other libraries that combine stats (or other data analysis) and plotting. The paradigm I always use is to do the analysis separately, and plot the final result focusing on presentation and formatting.

Matplotlib is the best I can find for this, despite the sometimes clunky interface. GNUplot is also good, but its easier to have a native python library.

One more thing I'll say that had heavily biased me, I started off with Matlab, and I find that matplotlib is the closest to Matlab plotting, which is a lot of why I like it.

I agree that it is nice to have a native python library, but I'd argue that the gnuplot interface is much better designed than matplotlib.

I’ve used both, have written dataviz libraries so know less than zero, and have never seen this distinction made nor agree with it.

I wouldn’t even consider the two to have different purposes. Let alone “drastically” different. Drastically different api’s? Definitely. But purpose? No way.

The distinction between "stats" plots and "science/engineering" plots is a pretty standard thing for every scientist I have worked with. Data for stats plots is usually represented well in a dataframe. Data for "science/engineering" plots does not always make sense as a dataframe. One is a small subset of the other. Maybe we are in different fields but for anyone I would be working with it is screamingly obvious that these two libraries have different goals. How would you even make cut-axis quiver plot over 3D isosurfaces and 2D contour projections with a bunch of insets for instance in ggplot? In python, matplotlib would be the obvious choice and it is better than pretty much all R or Julia options in terms of fidelity of control (Makie.jl is getting there and has a good interface). I do not think ggplot is at all capable of that, and it would be silly to do it with ggplot anyway given that the input data is not represented by a dataframe well.

“How would you even make [super specific plot]?”

Ask on stack overflow, but a 10 second google shows that geom_quiver is a thing.

From my view, the bigger distinction confounding your point is that most people doing non-dataframe oriented engineering work are using Matlab/Python/Julia over R. That would explain the preference for matplotlib, as the api was literally inspired from matlab (an inspiration shared by Julia as well). But I expect it’s more of a convenience thing than anything - why shove a specific part of a different language (tidyverse api for R) into your workflow when the existing solution already works enough?

But R can work just as well, especially given the myriad of tertiary packages designed to transform your data into a “tidy” data frame (eg tidyr).

In any case, if you’re goal is something complicated or bespoke, wrestling with matplotlib is probably the least friendly option available, but ggplot isn’t the best option either. You should just use JavaScript.

You know that "non-dataframe oriented engineering" is most of physics and engineering, right?

It was not a super specific example, it was a standard example of a plot of a field, a type of data that makes no sense as a dataframe. I know that ggplot is great at what it does but why can you not accept that your work and the tools you like using for your work are a small subset of dataviz? I am sure you are great at your corner of it, but the suggestions you are making are just silly for other types of very common dataviz.

And the "inspiration shared by Julia as well" comment is just factually wrong if you are still talking about dataviz libraries. It is *mostly* wrong about the language as a whole.

And using JavaScript is a silly suggestion if you want publication quality static plots. And D3 is a ridiculously bad suggestion for engineering plots that is drastically more difficult to use than matplotlib for bespoke engineering visualizations. The reason matplotlib is the library used for the vast majority of physics and engineering journal papers is not simply inertia, it is the ease with which it customizes engineering plots.

Most of my work takes 30ish lines in matplotlib (the nicer OO interface), is impossible in ggplot, and would take hundreds of lines in D3. But yes, when I work with data frames, of course I would use something like ggplot, not something like matplotlib.

Seaborn is based on matplotlib and has basically the same semantics of matplotlib with better styling defaults and a wider API for different plots.

For a ggplot grammar-of-graphics style library in Python, I really like Altair: https://altair-viz.github.io/

The semantics differ and the API is actually more restricted (and friendly), not wider, but yes, I agree it is not grammar of graphics. However, as much as I love the grammar of graphics, it is important to point out there are other good ways to make stat plots besides it. Seaborne, bokeh, statsplots.jl, algebraofgraphics.jl, and others.

Definitely. One of the big problems, for me, is that there are at least two completely different interfaces with incompatible function names and arguments. While the object-oriented interface is frequently recommended, the pyplot interface is more commonly seen in stackoverflow questions and answers. Official documentation often shows examples only using one or the other. So you might have a mostly-functioning Object-Oriented plotting script, then wonder something like "how can I create another set of y-axis tics going along the right, showing temperature in fahrenheit", and only find slightly-similar-but-incompatible explanations that use the Pyplot interface.

It makes, by example, a pretty strong argument for not allowing multiple ways of doing something.

What's the object-oriented interface? I've only ever used pyplot l.

  fig, ax = plt.subplots()

then make calls on the Figure and Axes objects.

https://matplotlib.org/stable/api/index.html#usage-patterns

But note that, while it doesn't expose global state, it is still not thread-safe. The documentation only says that it "may work" and that there are specific things that will certainly crash when used from different threads.

https://matplotlib.org/stable/faq/howto_faq.html

I got my head around it eventually. Anything imperative that implicitly operates on the current figure/axes just calls the OO method on gcf / gca (get current figure / axes).

I often use the imperative API as it’s less typing often, and I do a lot of throwaway plotting code. But some functionality only exists in the OO interface. Then it’s an easy trip to gca().my_oo_function() and you recovered the imperative version.

That's a good point. It might be less clear how to find the OO function that corresponds to a given imperative command.

Kind of a crappy answer, but just read the source. pyplot is defined in a single file, so it's pretty search to search (for example here: https://matplotlib.org/stable/_modules/matplotlib/pyplot.htm...). Or just clicky-click on 'source' link on the pyplot doc page for a call (for example: https://matplotlib.org/stable/api/_as_gen/matplotlib.pyplot....) will take you to: https://matplotlib.org/stable/_modules/matplotlib/pyplot.htm...

And for most (not all) of the functions, it's an easy read to figure out the OO call.

This is because matplotlib is mostly a faithful copy of Matlab's plotting functionality. Matlab has the same set of two interfaces with the purely imperative one being the older one of the two. The more object oriented interface is a later addition there.

There's my gnuplotlib library also: https://github.com/dkogan/gnuplotlib/

I claim it's worlds better.

After reading through the user guide [1], I found that it does have decent (although not super clean) object model and the all SO-suggesting cryptic APIs are Huffman-encoded shorthand. With the right mental model, Matplotlib became much less intimidating than what it originally was. So, I'd suggest you RTFM if you found it funky.

I'm mostly using Altair instead these days since my data is mostly tabular, but Matplotlib still maintains a position in my toolbox and helps me when I need some dirty (or creative) visualization that is tricky with Altair.

And to be honest, I occasionally miss Matplotlib's dense API when I'm fed up with the verbosity Altair has. Yes Altair code is more readable, I agree with the proposition, but being quick and dirty can be lovely sometimes.

- [1] https://matplotlib.org/stable/users/index.html

- [2] https://altair-viz.github.io/

When doing my master thesis, I wanted my plots to be printable on a black and white printer in case my professor would print or photocopy it (you never know)

I wrote up a blogpost about my findings on how to generate monochrome plots. I haven’t really used matplotlibs since my thesis days, but it’s kinda funny to see what my thoughts back then were on the interface.

I found the OO interface a necessary evil and that you have to mix interfaces to get full control of your plots.

Maybe things have been ironed out in the past 5 years? Reading the comments here it seems like the sentiment is that the OO interface is considered the sane, true interface.

http://olsgaard.dk/monochrome-black-white-plots-in-matplotli...

I still wonder why no one speaks about Altair and their grammar of graphics thinking. I think they are wonderfully intuitive and I wish I had discovered them earlier.

I’ve switched away to Plotly a while ago. It matured a lot in the past year or two. It’s extremely easy to use and I’ve been holding presentations with it routinely. It’s worth a try.

https://plotly.com/python/

I haven’t used matplotlib since! (over 2 years)

Reply on news.ycombinator.com