KVkvnhn·May 3, 2024Submission
"No" is not an actionable error message
3 points · Open discussionmwaskom
seaborn
Python2013–2024
mwaskom / seaborn
seaborn
Statistical data visualization in Python
11Distinct people
11Mentions
0Explicit recommenders
14.1KGitHub stars
What to know before exploring
What it is
Statistical data visualization in Python
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year11 dated mentions
Observed mentions: 2013-11-25 16:42:21 UTC to 2024-05-03 19:53:03 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 1 | 1 |
What Hacker News says
11 sourcesThe seaborn issue linked in the paper, “Treat binwidth as approximate to avoid dropping outermost datapoints” (https://github.com/mwaskom/seaborn/pull/3489), summarizes the problem as follows:
> floating point errors could cause the largest datapoint(s) to be silently dropped
However, the paper does not contain the string “float”, instead saying only:
> A bug in the seaborn 0.11.2 plotting software [3], used by Park et al. [1], silently drops the largest data points in the histograms.
So at the very least, the paper is silent on a key aspect of the bug.
In Seaborn bug responsible for finding of declining disruptiveness in scienceNew ggplot/Altair like interface for Seaborn now in beta
2 points · Open discussionI ran into this once when I tried to replicate a virtualization with seaborn using the jet colormap: https://github.com/mwaskom/seaborn/blob/master/seaborn/palet...
In Which color scale to use when visualizing dataI would strongly recommend against anyone using Seaborn.
I used it for charts in a paper recently, since it includes swarm plots. I hit a problem when overlaying certain types of plot on the same axes (I think it was swarm plots on top of box plots, so I could show every data point as well as the quartiles). The problem was that the data would end up shifted, so the x axis labels weren't correct, even though each plot on its own would work fine when the other was commented-out. The only reason I noticed this was because I spotted that a peak I knew occurred at x=13 was showing up at x=14.
Although it took a specific set of circumstances to trigger, I thought this was still a serious problem since it causes data to be misrepresented, and it doesn't cause any warning, etc. that something is wrong. I made a minimal example script, opened a g
Read the rest
ithub issue ( https://github.com/mwaskom/seaborn/issues/1409 ), where the library author insulted me and locked the issue. I sent them a followup email, to explain that I was not after "free tech support" (I'd already worked around the issue for my paper by 'faking' the labels), I wanted to help improve the library so that others would avoid having incorrect plots (especially those not lucky enough to spot it like I was) and how I'd already spent considerable time narrowing down the problem to the minimal example, as evidence that I wasn't trying to be a freeloader. I also began my email with an apology for using this side channel, and that I wouldn't contact them again unless they consented to it. The author replied with more insults.
I didn't contact them again, as promised, but now I'm actively opposed to anyone using this project, due to the author's complete disregard for corruption of scientific data.
My biggest problem with ggplot is that it's slow, unbearably slow. It also enforces all data to be realized into a single dataframe, which is true only for small (as is: fits in memory) datasets.
Very often, to produce specialized plots, I have to send data to the canvas in chunks by performing pre-processing myself. ggplot really doesn't work in this scenario. Combined with the general slowness, it forces me to use alternatives quite frequently.
It's a bummer, really, because I'd like my plots to have a consistent visual style, and doing that across different plotting packages is an issue.
I very often resort to gnuplot when it comes to huge datasets and/or incremental plotting. The same is true also in python (matplotlib is also very slow, independently of the backend). But at least, if you use seaborn (https://github.com/mwaskom/seabor
Read the rest
n), you can easily intermix the easiness of plotting through a DataFrame or just supply data arrays.
ggplot is really awesome for what it does, but 1) the syntax doesn't really please me (feels just plainly forced onto the wrong context 2) doesn't scale, which forces me to use alternatives too frequently 3) trying to customize the plot style beyond a few minor tweaks is pure hell.
For stats plotting in python:
https://github.com/mwaskom/seaborn
https://github.com/yhat/ggplot
For stats plotting and web apps in python:
https://github.com/bokeh/bokeh
For calling r libraries in python:
https://pypi.python.org/pypi/rpy2
For out of core datasets in python:
https://github.com/blaze/dask
https://github.com/blaze/blaze
In Python, Machine Learning, and Language Wars. A Highly Subjective Point of ViewSeaborn: a high-level Python interface for drawing statistical graphics
134 points · Open discussionMPL's documentation is a catastrophe, and the API design is indeed abysmal. The plots, however, are only as ugly as you like them to be. Here's a great auxiliary package with much more sensible defaults:
https://github.com/mwaskom/seaborn
In Data analytics with Pandas and SQLiteFor ggplot - there is (sort of) a clone of it for Python, https://github.com/mwaskom/seaborn. And it has, arguably, better graphics.
As a Python user, who resorts to R in case of need, the power of R is not in the language, but statistical community & packages.
In The R language, for programmersSeaborn: statistical data visualization
1 points · Open discussion