Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Nice package! A side-by-side comparison with seaborn would be very nice to see.by skimmed
- Using operator overloading of "+" to configure the plot is... a choice.by jstanley
- It is! And that's kinda the point.
Like others mention, this is inspired by ggplot2, a Grammar of Graphics library. The whole idea is graphics are composed by adding "layers", not like layers on a canvas, but like pouring paint into a pot, then the library understands the content and paints it to the canvas.
Layers might be pure data, geometry (lines, points, ...), annotations, styles, axis, etc.
When you get familiar with it, it's much more natural way of describing plots, better composition and easier exploration
- Plotnine is heavily inspired by the ggplot2 library, which uses the + operator in the same way: https://ggplot2.tidyverse.org/#usageby jamessb
- I use agents more and more for generating and refining plots, and its difficult for me to see the difference between matplotlib, seaborn, and plotnine, when used in this way. Agentic coding seems especially well suited to working with scientific figures, and that performance seems more or less agnostic to the underlying framework used (though they seem to prefer matplotlib, given the amount of training data for using that tool). I'm totally open to the idea that better libraries will lead to better outcomes from agents, but I haven't seen that with plotting yet.by jablongo
- I have used neither in quite a while now but there is an alternative from jetbrains that i started using because it shares the same ergonomics and had better (?) documentation.by a_ba
- It seems like the major difference between plotnine and lets-plot is that plotnine wraps Matplotlib (and thus works everywhere Matplotlib is available, but doesn't offer much interactivity), while lets-plot is written in Kotlin and seems to provide interactive plots.by ForceBru
- matplotlib is what most folks reach for by default, but I'd argue that's habit and popularity talking, not a real fit advantage. For a lot of plotting work, the grammar-of-graphics libraries — Altair, plotnine — may be the better tool for many people (and Agents); they just don't have the muscle memory behind them.
(Disclosure: I'm at Posit, which supports plotnine.)
by icarusz - It supports plotnine via plot display window, do you mean?
- What would you say are the benefits of the grammar-of-graphics approach? I've been working with plotting for more than a decade now and have never heard of it. Right now I'm looking through the gallery and can't really grasp what makes this approach better than the one in matplotlib.
PS. It took someone in the comments writing "import plotnine as p9" for me to understand it isn't plotLine.
by jllyhill - It is great, but I have completely given up non-interactive plots since a while.
You get so much more information in plots using bokeh (or I assume plotly).
Tooltips, zooming, interaction.
And the LLM helps a lot when the plot is a bit more complex.
by fifilura - And it comes with tidyverse-like cheatsheet[1] that I confused with ggplot2 when first discovered plotnine
[1]: https://github.com/rstudio/cheatsheets/blob/main/plotnine.pd...
by qrobit - Sorry for the confusion. Though, it is a mango tree in a mango garden! The continued development and maintenance of plotnine is supported by Posit, PBC, the same company behind the Tidyverse.
Disclaimer: I am the author.
by has2k1 - I've always liked the ggplot2 and the Grammar of Graphics approach to plotting so much so that I wrote my own DSL based on it - it is standalone, written in Rust, has WASM bindings (as you can see on the website) and more:
https://williamcotton.github.io/algraf
It pairs well with a related data translation DSL:
https://williamcotton.github.io/pdl
And you can see the two working together here:
https://williamcotton.github.io/datafarm-studio
There's LSPs for both, LSP clients for VS Code, and even language diagnostics for standalone Monaco editors in the browser.
Of note is that the same language diagnostics are exposed via the WASM as via the LSP interface allowing for the same friendly red squiggles to look and work the same in both your browser with Monaco and your editor with the LSP!
- Nifty! What motivated you to create these tools?by tmoertel
- A year ago, added R to the pipeline (with multiple complications) just to use ggplot2 - even though Python was the main tech.
https://quesma.com/blog/sandboxing-ai-generated-code-why-we-...
Good, that ggplot2 can run inside in WASM, vide https://github.com/QuesmaOrg/webr-ggplot-playground
by stared - This is definitely one of the better Python plotting libraries out there, but no matter which one I use, they make me yearn for R.
The R language is just so much more beautiful than Python, in its full lispy goodness, with lazy evaluation.
It doesn't matter quite as much now that I have LLMs write a good chunk of the plotting code. But the LLM python plotting code is easily 5x-10x as many lines as a hand-crafted R plot, making it slower and harder to grok than R.
by epistasis - This is going to sound superficial as hell, some things are just horrendously ugly in R. Like the various pipe operators. %>% might just be the ugliest I've ever seen, in any language (and, yes, I know why you need % %).by TrackerFF
- Hey! I worked on the plotnine guide (https://plotnine.org/guide/). Always interested to hear what people find hard to understand about plotnine, or what they wish there were more of (e.g. examples, guide pages, api reference docs).
(Both has2k1 and I work for Posit, which supports plotnine work, but authoring its guide was mostly an act of passion for me :)
by closed - Plotnine has been great in my usage, but I see violin plots on the front page. Just say no to violin plots.
In almost any situation you either want to talk about the actual distribution (in which case plotting the distribution on one side of the line arranged horizontally is significantly superior to plotting it vertically on both sides of the line for some reason as a violin plot does[1]) or you want to talk about the quartiles etc in which case a boxplot is better.
A violin plot tries to do both and as a result does them both badly.
Extended anti-violin plot rant here https://www.youtube.com/watch?v=_0QMKFzW9fw
[1] I remember in one meeting before I knew better, producing some violin plots and putting them on a slide and I knew I had gone wrong when that slide came up and everyone in the room had this confused expression on their faces and was leaning their head over to the side to try to see the distribution better. When your visualization produces obvious confusion like that, you can be completely certain it has failed.
by seanhunter - You couldn't pay me enough to be this opinionated about something so banal.by mathisfun123
- The arguments in the video are mostly misdirected, conflations of related but distinct issues, or (hypocritically) just opinions. Here are the unpacked issues as I see it:
1. Whether to summarize data by a handful of summary statistics or a full density. Obviously, some statistics reported in isolation can misrepresent the underlying distribution, but these considerations ultimately depend on what specific point one seeks to make with a plot. There's no reason a priori that visually annotating summaries/quantiles on a distribution plot can't be helpful (quite the contrary).
2. Whether to "smooth the data" (read: perform kernel density estimation). In some sense this is a long-solved problem: there are mathematically grounded methods for estimating the optimal KDE bandwidth (with varying degrees of assumption on the underlying distribution), which are what's used by any serious plotting library. And whether authors adequately describe what they're actually plotting is a separate matter. That said, there are many reasons not to show a KDE over, say, a binned histogram, especially with raw data and/pr small sample sizes, but these are entirely orthogonal to the choice of displaying a KDE as a violin plot versus something else.
3. How to normalize densities. With raw data, you probably want to compare frequencies (a proper pdf). If displaying just a single distribution, there's obviously no reason not to show the density (it's only a trivial rescaling of the axis tick values). When comparing multiple, the decision again depends on the point of the plot. Losing dynamic range for broader densities when compared with narrower ones can be counterproductive. E.g., in Bayesian parameter inference (where the data are MCMC samples), we almost never compute the actual normalization factor, but rather want to compare relative probabilities (i.e., within a single distribution) of different parameter values across different distributions. Of course, nothing forces one normalization over another for violin plots.
All of those are separate (and rectifiable!) issues from the defining characteristics of a violin plot:
1. Distributions displayed vertically rather than horizontally (both being harder to interpret and inappropriately suggestive). We almost exclusively visualize functions plotted vertically across a horizontal coordinate. I think this is the only valid, specific criticism of the common violin style itself, but the fix is of course trivial.
2. Horizontal violin are then only different from a ridge plot by a) not overlapping (which to me is a major improvement over standard ridge plots, but also trivially fixed) and b) being displayed symmetrically. I find it slightly easier to compare relative heights in the symmetric version, especially when comparing many distributions (such that each is relatively narrow). Even if not, the difference is so superficial/trivial that I don't find it worth arguing about.
Beyond this, the video's main argument (repeated every minute) seems to be that "it's bad, it's just bad", but there are only so many ways to make a 5 minute argument fill a 42 minute video. (This style of video is so grating to me.)
by suuuuuuuu - Violin plots have an interesting reputation (https://xkcd.com/1967/, https://www.reddit.com/r/labrats/comments/91ex4u/is_it_just_..., https://jabde.com/2022/12/22/banned-violin-plots/).
For showing distributions, I much prefer strip plots (https://seaborn.pydata.org/generated/seaborn.stripplot.html), perhaps with opacity, or swarm plots (https://seaborn.pydata.org/generated/seaborn.swarmplot.html) - no averaging with an unknown kernel, no hiding distributions behind a box plot, and the data is directly visible. We also directly see whether it is based on 5, 100, or many more points.
When using histograms, binning is usually more straightforward than kernels. And in any case, the mirror reflection of a histogram is not needed.
by stared - If you already use plotnine, or if this has piqued your interest, the next release (v0.16.0) will bring nice capabilities.
You can get a sneak peek by installing the pre-release:
pip install --pre plotnine
Details here: https://github.com/has2k1/plotnine/issues/1031
Disclaimer: I'm the author.
by has2k1 - Minor nit, the "Installing" link on the linked page leads to the general documentation.by jjgreen
- Love your work on this, thanks for bringing the ggplot syntax to Python!by x312