Consider a possible "methods-based" interface.

[iangow]

I have heard it said that plotnine is "not Pythonic". I explore this claim here and I conclude that perhaps the claim is strongest with the need to either say from plotnine import * (or at least from plotnine import [lots of things]) or make the code ugly with import plotnine as p9 and then p9.ggplot(p9.aes()) + p9.geom() + ....

With the help of Codex, I made a feature branch that provides a more "methods-based" interface on a fork here. The code changes seem quite non-invasive.

I think the "methods-based" code looks quite Pythonic. I also made a demo site here and everything seems to "just work" so far.

[iangow]

Perhaps some place out of the way like plotnine.objects (mirroring Seaborn's objects interface) might be a natural place for this. Basically plotnine.objects could just add_fluent_methods(ggplot) and nothing else would change (though maybe tidier if re-exports things from the "main" plotnine, so you could do from plotnine.objects import ggplot, element_text or whatever).

The more I look at Seaborn/Matplotlib, the more impressive plotnine seems. Someone directed me to this today: https://stackoverflow.com/questions/4700614/how-to-put-the-legend-outside-the-plot

I'm not sure I want to get a PhD in Matplotlib!

[TyberiusPrime]

I believe this out of scope for plotnine, which explicitly mirrors the ggplot2 api.

That being said, I also like my plotnine fluent, so I wrote
dppd_plotnine which wraps p9 objects upon request.

It has one more big change, "color" is an aes, while "_color" is a non mapped argument. I find this natural, but it's a step further away from ggplot. See https://dppd-plotnine.readthedocs.io/en/latest/aes.html

[iangow]

I believe this out of scope for plotnine, which explicitly mirrors the ggplot2 api.

If so, this does mean that plotnine feels a bit like a plotting package for R users who miss ggplot2 (and it's hard to blame them) rather than a thorough implementation in idiomatic Python of Hadley's interpretation of the Grammar of Graphics. Using from plotnine import * and then doing everything with functions is common R style, but it's not very "Pythonic".

Yes, you can do import plotnine as p9 and then p9.ggplot(p9.aes()) + p9.geom() + .... But relative to a methods-based approach, you're adding needless + p9. characters where . would suffice.

It seems there should be an excellent Python implementation of the Grammar of Graphics that doesn't carry the baggage that comes from it happening to have been first implemented in R. Seaborn objects is definitely not that implementation. (There's too many plotting packages to try them all.) But plotnine really almost is.

That being said, I also like my plotnine fluent, so I wrote dppd_plotnine which wraps p9 objects upon request.

I can't really do that for my purpose. I'm translating a book that has code for Python users. So "use my custom plotting package" doesn't work. But I don't think I want to add from plotnine import * to every chapter. So for now I'm grappling with the awfulness of Seaborn/Matplotlib (it is very common for four lines of ggplot2 code to become 20 lines with Seaborn/Matplotlib, even though the plots look worse).

It has one more big change, "color" is an aes, while "_color" is a non mapped argument. I find this natural, but it's a step further away from ggplot. See https://dppd-plotnine.readthedocs.io/en/latest/aes.html

[TyberiusPrime]

Such 'code examples' are one of the big advantages of plotnine mirroring ggplot2 so closely - the R code transliterates with almost no changes, you can apply the ggplot2 book in python without hassle, etc.

Remember, it is not just an API, it's a whole grammar of graph(s|ics).

It's so entrenched in the visualization space, there's even a 2nd python implementation (lets-plot) that also follows the grammar as proposed.

But I'm only a very minor contributor and this isn't my show - if @has2k1 wants to support a fluent API, I certainly won't mind.

[iangow]

Such 'code examples' are one of the big advantages of plotnine mirroring ggplot2 so closely - the R code transliterates with almost no changes, you can apply the ggplot2 book in python without hassle, etc.

But offering a fluent API doesn't change anything about that. Just as the Seaborn objects interface doesn't change anything about how existing Seaborn code works.

Remember, it is not just an API, it's a whole grammar of graph(s|ics).

Yes, ggplot2 is an implementation of the grammar of graphics implemented in an R way (i.e., functions, not methods). plotnine is an an implementation of the grammar of graphics implemented in an R way in Python. Don't get me wrong, what plotnine is able to do with Matplotlib (in a way that Seaborn really doesn't) is simply amazing. I just think it would appeal to more people if it offered an additional, more 'Pythonic' API. (Also, I don't think overloading + is in any way 'not Pythonic', but having to import many methods [often from plotnine import *] arguably is.)

It's so entrenched in the visualization space, there's even a 2nd python implementation (lets-plot) that also follows the grammar as proposed.

I don't think anything is "entrenched" in Python visualisation space in the way ggplot2 is. If I decided to learn data science in R, there's a very good chance that I'm going to be nudged to ggplot2. But coming to Python over the last couple of months, I've seen materials using Matplotlib, Seaborn, Seaborn object, Altair, plotly, hvplot, plotnine, lets-plot, … And also the claim from experience Python users that "plotnine is 'not Pythonic'".

But I'm only a very minor contributor and this isn't my show - if @has2k1 wants to support a fluent API, I certainly won't mind.

Indeed. I am not a contributor in any way, but I think having something more 'Pythonic' would help attract more users, etc.

[iangow]

Interestingly, great_tables (another Posit-supported Python port from R) seems to run with a more methods-based interface than the original R version (which, idiomatically for R, emphasizes pipes and functions).

[iangow]

Maybe something like this would make more sense if there were an import plotnine.polars that registered a DataFrame namespace (a bit like what import hvplot.polars does). That namespace plotnine or ggplot could then be used as df.ggplot.plot() or even df.ggplot(). In that context, a more methods-oriented approach seems quite natural. I did a quick demo here.