Plotnine: Grammar of Graphics for Python (2019) - https://news.ycombinator.com/item?id=25948840 - Jan 2021 (37 comments)
Plotnine: A grammar of graphics for Python - https://news.ycombinator.com/item?id=14430447 - May 2017 (38 comments)
71–80 of 83 posts
Plotnine: Grammar of Graphics for Python (2019) - https://news.ycombinator.com/item?id=25948840 - Jan 2021 (37 comments)
Plotnine: A grammar of graphics for Python - https://news.ycombinator.com/item?id=14430447 - May 2017 (38 comments)
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 t…
You couldn't pay me enough to be this opinionated about something so banal.
The marriage of stats and design can bring the worst from both.
(And even if you find that plot X is bad, that doesn't mean you need to treat it as a personality trait.)
Love plotnine when I switched over to python and great to see the project develop! But I have to admit I ended up switching to altair after all which has been my go to in python now.
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.
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 pl…
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 pl…
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 % %).
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 pl…
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 % %).
The visual impact of a %>% or a |> or whatever fades within a few minutes of reading code for me, what I'm looking at for beauty relates more to the AST structure. Lack of repetition, ease of understanding the data flow, ability to adapt the data flow, etc. that's what makes code beautiful to me.
Nice one. I'm aware of plotnine because ggplot is more intuitive IMHO than say matplotlib. 2 things that would be awesome are interactive plots (hover + text box) and chlorpleth (tiled map) plots. On closer look you have already nailed the latter!
There is this new and very promising package that adds interactivity to plotnine graphs https://y-sunflower.github.io/ninejs/ . Disclaimer: I am the author of plotnine.
Earlier quoted context omitted.
Because, in the latter case, you have to declare a function argument for /every possible option/ that you want your graphics API to expose, and you need to do this every time you add a new option. On the other hand, declaring the options through composition means that the API for "plot" remains static, and adding/removing options can be done trivially without an API change. Composition (rather than parameters) is als…
kwargs exists, and is rather more pythonic. Just pass the kwargs dict to a standard formatting function, et voila.