I know that web technologies are all the rage these days, but at least for static, publication-ready graphics, Grid is really nice substrate, with well thought out lower-level abstractions.
EDIT: I should also add that it's documented within an inch of its life should anyone feel that it's worth recreating: https://stat.ethz.ch/R-manual/R-devel/library/grid/html/grid...
ggplot2 being built on top of Grid means that modestly complex stuff is easy (in ggplot2 by itself), but that it's relatively easy to drop down into the lower layer (grid) to do more.
I also want other packages to be able to build off of plotnine, e.g. a package with the functionality of Seaborn could be built off of plotnine. The only constraint should be whether the backend -- in this case Matplotlib -- does stand in the way. Matplotlib is evolving (though slowly) and has a very receptive community so there is lots of hope.
* - Many people contributed to its history.
As an alternative that preserves the full power of Wickham's implementation, pygg is a Python wrapper that provides R's ggplot2 syntax in Python and runs everything in R.
x='age', y='height', color='sex')
I don't mean to undermine your project, just wanted to know about significant differences.
Also the last commit to the yhathq ggplot library was on Nov 20, 2016, so this library looks like it is currently more active in development.
Edit: Someone made an article comparing the two here: http://pltn.ca/plotnine-superior-python-ggplot/
- plotnine has 1,283 commits, 42 contributors, most recent commit is 3 days ago.
The only comparison that is important is how well the two projects work. I have no idea how well plotnine works yet (but I intend to find out). I do know that ggplot works OK - and seeing as it leverages matplotlib if there is anything that isn't implemented I can finish the plot off manually.
EDIT it seems that plotnine also leverages matplotlib and produces nicer plots for some common cases :).
Without additional context I find recency of last commit and number of committers to be almost impossible to draw useful conclusions from.
"On average, X is better than Y."
"Ah but I would rather have the top end of Y than the bottom end of X, therefore comparing averages is useless."
Yes, a brand new Ford Focus would be better than a Ferrari that doesn't run, but generally Ferrari is the better brand.
The earlier poster in this thread implied that number of contributors and recency of commits in one of two competing github projects was evidence that it was better.
My point is that these are inadequate (often totally misleading) heuristics unless both projects are otherwise extremely similar, which they usually are not, and even then are usually not very useful heuristics compared to other ways of comparing the projects.
Unless you know who the authors are, what the project management/organization style is, how the project is funded / what level of commitment the authors have, what the project release cycle is like, etc., or unless you directly examine the code yourself, the only thing that looking at the most recent git commit tells you is how recently someone published public code changes. Which is not something that anyone evaluating two projects cares about directly, but only as some heuristic signal of other features that might be more costly to examine.
But note that commit recency doesn’t give a remotely useful sense of how extensible the project is, how readable or efficient the code is, how well designed the API is, how good the documentation is, how friendly the community is, how competent the project management is, .....
If we want to make a car analogy, it’s like choosing which car to buy based on how frequently the company introduces new models, or how many engineers they employ, rather than based on customer reviews, reliability estimates, accessibility of mechanics, gas mileage, top speed, or storage capacity.
Your argument is basically analogous to: “because the average car with frequent updates is better than the average car with infrequent model updates, criticizing that as a primary criterion for choosing a car is an invalid argument”. Notice that you haven’t even bothered to examine whether your premise about the relation between updates and quality is true, or whether that average relationship makes update frequency a practically useful heuristic or not.
One useful conclusion: security bugs are likely to be fixed in a timely manner that won't put your users at risk.
For example, how often does DJB publish new code changes to his various projects?
Is it the way we concatenate functions to create what's essentially a sentence of what we want the plot to be?
and Hadley Wickham wrote about it in http://vita.had.co.nz/papers/layered-grammar.pdf.
I'm no expert, but I think that one of the main ideas is to separate the elements of making a plot from the way that the data is presented. For example, in ggplot2, you have the data that will go into the graph, the type of plot (or "geometry") that defines how the data are presented (scatterplot, bar plot, etc.), and then various "layers" that can be added that affect style.
In order to split a plot into subplots, you simply define how it is to be faceted (what column should be used to define groups). Grammar-of-graphics moves plotting away from the "turtle graphics" model and lets you specify what should be done. Then ggplot figures out how to do it, kind of like SQL vs. writing for loops to retrieve information.
If I'm to dig in the manual, I might as well build my plots with the standard syntax of any random plotting library.
Is this "grammar of graphics" any good if you invest more time in it?
Layers are as follows 
2. Aesthetic mappings
3. Statistical transformation (stat)
4. Geometric object (geom)
5. Position adjustment
Once you get a hang of this, it becomes easy to create new plots purely from the understanding of the layers. In matplotlib or even in Seaborn, I find myself constantly Googling for examples.
ggplot2 is the most beautiful thing to happen in visualization space!
 Wickham, Hadley, and Carson Sievert. "4.4.1 Layers." Ggplot2: Elegant Graphics for Data Analysis. Dordrecht: Springer, 2016. N. pag. Print.
For some, it was probably one of THE things that kept them using R over something else. Yes, definitely worth it.