By the estimation of one esteemed colleague "it obviously pays back the time investment in less than a couple of days". I agree.
(ggplot(mtcars, aes("wt", "mpg", color="factor(gear)"))
+ geom_point()
+ stat_smooth(method="lm")
+ facet_wrap("~gear"))
My problem with all the popular plotting libraries in python is they seem designed for researchers slapping together a paper and produce code that's awful to maintain.
This criticism doesn't do anything for me.
Is an alias for a 3 letter function name really going to improve readability / usability? It's the same API. Take it up with Hadley Wickham.
I think having one interface that is the same (ok, "mostly the same") for R and Python is a blessing for people who work with both. I don't graph with Python much, but every time I have to plot in Python I sigh and ask myself if it would be easier to just import the data into R.
In this case, absolutely. Plus it shows the attention to detail, or lack thereof, across the whole API.
- Why isn't the first term `ggplot(mtcars, "wt", "mpg", color="factor(gear)")` instead? It seems that the second argument always has to be a `plotnine.mapping.aes(...)` call or a saved `aes` value. It is not really hard to distinguish `ggplot(data, saved_aes)` from `ggplot(data, "x-col", "y-col", ...)`. The only issue might be the third `environment` argument, but that can go elsewhere (see below).
- What's up with that operator overloading? Is `+=` even supported? It seems that the original R version had the same syntax, but Python's statement-based syntax makes it annoying to use. Maybe any "additions" should have been moved into `ggplot` arguments by default: `ggplot(mtcars, "wt", "mpg", geom_point(), stat_smooth(...), facet_wrap(...), color="...")`.
- Many "addable" values have common repeating prefixes (`geom_` etc). Doesn't sound like a good API design at all, especially in Python. Probably there should be a `geom` module and so on that are exposed via `from plotnine import *` instead, so that `geom.point()` would work for example.
- Formulae as strings are fine to have, but it somehow has multiple "stages" where they can be evaluated (`after_stat` etc). Such feature would be necessary from time to time, but the concept itself doesn't seem to be not well polished.
It's also quite nice to be able to use the same interface in both R and Python, although it is obvious that it was originally developed for R.